Domain Model vs Anemic Domain Model

An object model of the domain that incorporates both behavior and data.

At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.

Domain model :
  • The objects are meaningful.
  • Behavioral responsibility finely defined between classes.
    So good isolation, testability, and maintainability.
    For example, adding/removing/unit-testing BonusRuleis easy.
  • Objects responsible of their state.
    Indeed, no need to provide setters as the object can itself update its state after collaborating with other objects.
    We could see that in Amount.applyBonus() :
    float bonus = bonusRule.compute(this); amount += bonus;
Anemic Domain Model :
  • All the logic is in the service class.
    So a single place to get the code.
    With a 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.
  • The necessity to provide getter/setter for domain classes.
    The domain is not responsible for its state and its invariant rules either.
    So any class that depends on the domain class can "break" its state.
As a side note, some frameworks (for persistence, mapping, serialization, ...) rely by default on getter/setter.
That's why this model, despite its drawbacks, leads in some projects.


Post a Comment