Anemic Domain model

Anemic Domain Model is the use of a software domain model where the domain objects contain little or no business logic. Instead of methods, the domain objects only contain data and the logic is implemented in services. This is often seen as an anti-pattern because it violates the principle of encapsulation and leads to a procedural style of programming.

Read mora about it in this article by Marting Fowler.

in short:

• All the logic is in the service class. So a single place to get the code. With few lines, it is fine. But note that this advantage has a certain limit because as the logic becomes big or complex, the best thing is often splitting the logic in multiple service classes.

• But whatever the number of Service classes you need, the whole logic is located in the service classes and not somewhere else. Which may ease development norms if we compare it to the domain model where the logic may be exploded in some different “types” of classes.

• Necessity to provide getter/setter for domain classes. The domain is not responsible of its state and its invariant rules either. So any class that depends on the domain class can “break” its state.

Note that some frameworks like Hibernate are designed to work with Anemic Domain Model. But it is not a reason to use it. Indeed, it is often better to use a Domain model and to adapt the framework to it, but it is a reason why this anti-pattern is so common.