Rich vs Anemic Domain Model [closed]

Solution 1:

The difference is that an anemic model separates logic from data. The logic is often placed in classes named **Service, **Util, **Manager, **Helper and so on. These classes implement the data interpretation logic and therefore take the data model as an argument. E.g.

public BigDecimal calculateTotal(Order order){
...
}

while the rich domain approach inverses this by placing the data interpretation logic into the rich domain model. Thus it puts logic and data together and a rich domain model would look like this:

order.getTotal();

This has a big impact on object consistency. Since the data interpretation logic wraps the data (data can only be accessed through object methods) the methods can react to state changes of other data -> This is what we call behavior.

In an anemic model the data models can not guarantee that they are in a legal state while in a rich domain model they can. A rich domain model applies OO principles like encapsulation, information hiding and bringing data and logic together and therefore a anemic model is an anti pattern from an OO perspective.

For a deeper insight take a look at my blog https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/

Solution 2:

Bozhidar Bozhanov seems to argue in favor of the anemic model in this blog post.

Here is the summary he presents:

• domain objects should not be spring (IoC) managed, they should not have DAOs or anything related to infrastructure injected in them

• domain objects have the domain objects they depend on set by hibernate (or the persistence mechanism)

• domain objects perform the business logic, as the core idea of DDD is, but this does not include database queries or CRUD – only operations on the internal state of the object

• there is rarely need of DTOs – the domain objects are the DTOs themselves in most cases (which saves some boilerplate code)

• services perform CRUD operations, send emails, coordinate the domain objects, generate reports based on multiple domain objects, execute queries, etc.

• the service (application) layer isn’t that thin, but doesn’t include business rules that are intrinsic to the domain objects

• code generation should be avoided. Abstraction, design patterns and DI should be used to overcome the need of code generation, and ultimately – to get rid of code duplication.

UPDATE

I recently read this article where the author advocates of following a sort of hybrid approach - domain objects can answer various questions based solely on their state (which in the case of totally anemic models would probably be done in the service layer)

Solution 3:

My point of view is this:

Anemic domain model = database tables mapped to objects (only field values, no real behavior)

Rich domain model = a collection of objects that expose behavior

If you want to create a simple CRUD application, maybe an anemic model with a classic MVC framework is enough. But if you want to implement some kind of logic, anemic model means that you will not do object oriented programming.

*Note that object behavior has nothing to do with persistence. A different layer (Data Mappers, Repositories e.t.c.) is responsible for persisting domain objects.