Edition 0 Updated to asp. Net core 0

Rich domain model versus anemic domain model 
In his post 
AnemicDomainModel
, Martin Fowler describes an anemic domain model this way: 
The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There 
are objects, many named after the nouns in the domain space, and these objects are connected with 
the rich relationships and structure that true domain models have. The catch comes when you look at 
the behavior, and you realize that there is hardly any behavior on these objects, making them little 
more than bags of getters and setters. 
Of course, when you use an anemic domain model, those data models will be used from a set of 
service objects (traditionally named the 
business layer
) which capture all the domain or business logic. 
The business layer sits on top of the data model and uses the data model just as data. 
The anemic domain model is just a procedural style design. Anemic entity objects are not real objects 
because they lack behavior (methods). They only hold data properties and thus it is not object-
oriented design. By putting all the behavior out into service objects (the business layer), you 
essentially end up with 
spaghetti code
 or 
transaction scripts
, and therefore you lose the advantages 
that a domain model provides. 
Regardless, if your microservice or Bounded Context is very simple (a CRUD service), the anemic 
domain model in the form of entity objects with just data properties might be good enough, and it 
might not be worth implementing more complex DDD patterns. In that case, it will be simply a 
persistence model, because you have intentionally created an entity with only data for CRUD 
purposes. 

---

201 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
That is why microservices architectures are perfect for a multi-architectural approach depending on 
each Bounded Context. For instance, in eShopOnContainers, the ordering microservice implements 
DDD patterns, but the catalog microservice, which is a simple CRUD service, does not. 
Some people say that the anemic domain model is an anti-pattern. It really depends on what you are 
implementing. If the microservice you are creating is simple enough (for example, a CRUD service), 
following the anemic domain model it is not an anti-pattern. However, if you need to tackle the 
complexity of a microservice’s domain that has a lot of ever
-changing business rules, the anemic 
domain model might be an anti-pattern for that microservice or Bounded Context. In that case, 
designing it as a rich model with entities containing data plus behavior as well as implementing 
additional DDD patterns (aggregates, value objects, etc.) might have huge benefits for the long-term 
success of such a microservice.