Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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.

like image 289
Andrew Siemer Avatar asked Jul 21 '09 00:07

Andrew Siemer


People also ask

What is an anemic domain model?

The anemic domain model is a programming anti-pattern where the domain objects contain little or no business logic like validations, calculations, rules, and so forth. The business logic is thus baked into the architecture of the program itself, making refactoring and maintenance more difficult and time-consuming.

What is the domain model in domain-driven design?

The Domain Model is your organised and structured knowledge of the problem. The Domain Model should represent the vocabulary and key concepts of the problem domain and it should identify the relationships among all of the entities within the scope of the domain.

What is the difference between domain and model?

A domain model is a representation of the organization's data, independent of the way the data is stored in the database, with a domain being the collection of all the objects in that system, while the data model is used in database design and development.


1 Answers

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.

like image 125
Jeffrey Hantin Avatar answered Oct 04 '22 05:10

Jeffrey Hantin