Anemic Domain Model's vs. Domain Model in a simple domain driven design

Question

I recently read a post on "The Anemic Domain Model Pattern" which caught my attention. As I read through this I found that the Anemic Domain Model description applied to many of the projects that I have worked on and built. I never thought of this as a bad design decision as it felt very natural. I thought that in the case where the domain model was light weight and not very complex the Anemic Domain Model moniker fit quite well. Why add complexity to the domain model where it doesn't need to be just so the title of "Anemic Domain Model" doesn't aptly describe your code?

Question: At what point does stuffing more of your code complexities into your service/application layer become in-correct in favor of exposing the complexity off of your entity objects instead? I am all for having a "Total" property on an Entity where it internally can figure out the value for the Total. I am not for making the Entity communicate directly with various other widgetry to determine the outcome of one of it's properties. So is the concept of an Anemic Domain Model an anti-pattern or a good separation of concerns? Is the title Anemic Domain Model always a bad thing?

Just curious what other people's thoughts were on this design (anti)pattern.

Answer 1

The key question is to ask why is the domain model anemic?

• Near-total absence of business logic, as in an application which is primarily an assemblage of CRUD screens?
• Service-oriented architecture in which the 'domain objects' are in fact simple structures data transfer objects?
• Political or pragmatic considerations such as code ownership or forward/backward compatibility that excessively impede refactoring?
• Applying procedural/relational design in an otherwise object-oriented language?

In any case, if I were to pick a simple rule of thumb for the boundary between domain model logic and service logic, it would be that interacting with related objects is fine within the domain, while accessing the "outside world" (user interface, web services, etc) probably doesn't belong in the domain model.

Answer 2

If the domain is lightweight (read: not complex), the recommended approach is to use a simple ActiveRecord-type objects in your core domain layer. Usually a one-to-one mapping between DB tables and your domain objects and there isn't a whole lot of "logic" here. Your app is just shuffling records between the database and your UI and allowing simple CRUD operations.

For complex domains, you would build out a core domain model where some of the objects end up mapping to DB tables and some likely do not and represent other concepts in your domain besides just plain data. The logic for the application should be inside the objects when appropriate or within Service objects if it requires the coordination between multiple domain objects.

The Anemic Domain Model anti-pattern applies to when you have a complex domain but instead of appropriately putting some logic in the domain objects and some logic in services, you put ALL (or nearly all) the logic external to your core domain objects.

The key difference here is where you put the logic. If you don't have much, obviously the domain objects will look like nothing more than simple data containers. If you do have complicated logic, don't just pull it ALL out of the domain objects but rather separate it appropriately between the core domain objects and domain services.

Answer 3

G'day!

If you put the logic outside the domain objects you lose one of the main OO concepts completely: encapsulation (or data hiding).

AOP makes it up to a certain degree, but after all, one of the key concets of object orientation is gone.

Regards, Stefan