Anemic Domain Model [Translation]

Against the background of my passionate study of DDD, I read Martin Fowler's November 25, 2003 Anemic Domain Model article . Sometimes, for a better understanding of the material, I translate it into Russian. So I decided to share the translation.
Author's translation and in some places very semantic.

Link to the original .

The article has quotes from an already published book, which was translated into Russian by professionals, in order to improve understanding of my translation, I quoted quotes from the book under spoilers.

The Pale Domain Model

This is one of those anti-patterns that has surrounded us for a long time, and is now even more active. I talked about this with Eric Evans and we both noted that he was becoming more popular. And as a supporter of the right Domain Model, I believe that this is not good.



The first symptoms of the Pale Domain Model is that it looks normal, but only at first glance. Objects are named as nouns from the subject area, are interconnected and have a structure like normal domain objects. Understanding comes when viewing their contents, it is hardly more than a set of getters and setters. Often, these domain objects come with architectural rules not to place any domain logic in them. Instead, there is a set of services (service objects) that contain all the domain logic in themselves. These services are architecturally above the domain model and use it as a data source.

The whole horror of this anti-pattern is that it runs counter to the basic idea of ​​Object-Oriented Design, which consists in combining data and process (behavior). The pale model is something like procedural design, just what fans like me and Eric have been struggling with since the very first days of their work with Smalltalk.

These days, Object-Oriented Purism is good, but I think we need more compelling arguments against this “pallor” in the model. The problem with the Pale Domain Model is that it carries the entire burden of the Domain Model without introducing its benefits. And we pay for it with the absurdity of database mapping, which usually spills out into an entire ORM layer. This only makes sense when powerful Object Oriented techniques are used to organize complex logic. However, moving all the behavior of the system to services, you need to understand that everything will end badly with Transaction Scripts , and of course you will lose all the advantages that the Domain Model brings. But as I said in P of EAA, the Domain Model is not always the best choice.

It is also worth noting that the placement of behavior in Domain Objects should not contradict the consistent approach of using layers to separate domain logic from the persistence and presentation layer. The logic that should be in the domain object is the domain logic, for example: validation, calculations, or whatever you call “business rules”.
(There are, of course, cases when you pass a data source or pieces of presentation logic to a domain object, but this is orthogonal to my idea of ​​“pallor.”)

One of the sources of misinterpretation is that many Object-Oriented experts recommend placing a layer of procedural services overdomain model, in order to form a service layer. But this is not an argument not to place the behavior in the domain model, in fact, the service layer encourages its use in conjunction with the domain model containing the behavior.

Eric Evans' excellent book, Domain Driven Design , says the following about these layers.

The application layer [as he calls the Service Layer]: defines the tasks that the application is supposed to solve and directs their execution to the (rich) domain model. The tasks of this layer are significant for business (not business logic) or are simply interaction with the application level of other systems. This layer should remain thin. It does not contain business logic or any knowledge, it only coordinates tasks and delegates work to sets of domain objects at a lower level. It does not carry a state that would reflect the situation in business logic, but it can know about the status of the task to inform the user and / or application as a whole.

Domain Layer (or Model Layer): Responsible for representing the meaning of business processes, carries information about the business situation and business rules (business logic). Here, the state that reflects the situation in the application (in its business part) is monitored and used, even if the technical details of data storage (persistence) are delegated and delegated to the infrastructure.
This layer is the heart of the application.

The point here is that the Service Layer is thin , and all the logic is in the Domain Layer. He (Eric) repeats this in his service template

Now it’s a common mistake to give up too soon when placing behavior in the appropriate object, gradually slipping into procedural programming.

I do not know why this anti-pattern is so common. I suspect this from the fact that there are so many people who did not work with the correct domain model, especially if they came from the data world. Some technologies encourage this anti-pattern, such as J2EE's Entity Beans, this is one of the reasons why I prefer POJO domain models.

In general, the more your logic in services, the more it seems that you left yourself without the benefits of the Domain Model. And if all your logic in services, then you stupidly robbed yourself.

Thanks for attention.

I do not pretend to invite, because I do not need it. But if someone thinks the material is worth the invite, just let me know in the comments, I will be pleased.