Is it a good idea to put business logic in domain/model objects ?

[Gayatri Ganesh]

Hi Everyone,

Domian objects are the objects in the middle tier of the application which model the application.
Till now I have been having properties on the domain objects and corresponding mutators.
Eg:

 
public class Car implements Serializable {
private String color;
   
public void setColor(String color) {
this.color = color;
}
 
public String getColor() {
return this.color;
}
}

Today I was reading a book which has a domain object with along with he properties and its mutators have methods which actually contain the business logic.

 
public class Car implements Serializable {
private String color;
   
public void setColor(String color) {
this.color = color;
}
 
public String getColor() {
return this.color;
}
 
public void start() {
//business logic on how to start the car.
}
}

I am wondering is this a good practise to put the business logic in domain objects ?

Thanks,
Gayatri

[Edited to add code tags - Paul Sturrock]
[ September 20, 2006: Message edited by: Paul Sturrock ]

[Paul Sturrock]

Discussions like this are usually better served in our OO, Patterns, UML and Refactoring forum. I'll move this there.

[Peer Reynders]

Originally posted by Gayatri Ganesh:
Domian objects are the objects in the middle tier of the application which model the application.

The domain model (and its objects) models the relevant part of the business for the application. In this context "domain" is simply a more general term for "business" because not all software deals with "commercial domains".

Originally posted by Gayatri Ganesh:
I am wondering is this a good practise to put the business logic in domain objects ?

The business logic, which is your domain logic, needs to be in the domain objects. If you aren't placing the business logic in your domain objects then you are most likely building a Smart UI, not a domain model. Smart UIs generally don't need a middle tier.

The Smart UI "Anti-Pattern" (Eric Evans; Domain Driven Design pp.76-78)

Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules with them. Use a shared relational database as a repository of the data. Use the most automated UI building and visual programming tools available.

Advantages

Productivity is high and immediate for simple applications.

Less capable developers can work this way with little training

Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests.

Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately. Expanding the system with additional, simple behavior can be easy.

Relational Databases work well and provide integration at the data level.

4GL tools work well.

When applications are handed off, maintenance programmers will be able to quickly redo portions they can't figure out, because the effects should be localized to each particular UI.

Disadvantages

Integration of applications is difficult except through the database.

There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply.

Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options.

Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.

Another case where business logic doesn�t end up in domain objects is when you capture your business logic in a bunch of transaction scripts. This often happens when business logic is placed inside session beans (which are deployed in the middle tier).

The point is: if your business logic is not in your domain objects then you don't have a domain model (and "your domain objects" aren't really domain objects).
[ September 20, 2006: Message edited by: Peer Reynders ]

[Ilja Preuss]

What Peer said. Also take a look at http://www.martinfowler.com/bliki/AnemicDomainModel.html

[Gayatri Ganesh]

Thanks Ilja.
That's an interesting website.