3 ms·

This is just the anemic vs rich domain model debate, the standard retort being https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pat

by daxfohl 11y ago

This is just the anemic vs rich domain model debate, the standard retort being https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/ https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain.... TL;DR: rich domain model causes an explosion of coupling (your User class is now coupled to your database, your screen, your rendering engine, your printer, etc, when all it really is is some user data). And the rich domain model simply breaks down when you need functionality on two objects (should it be user.render(engine) or engine.render(user); either way one of your domain objects needs to know some "private internals" of another). With the anemic domain model these problems don't exist.

anthony_d 11y ago
The coupling you mention was solved long before DI became popular. The service locator pattern isn't as transparent as DI but it solves the problem of course grained service dependencies.
- facorreia 11y ago
  You mean "coarse-grained", right?
jen20 11y ago
This is a gross misunderstanding of a rich domain model. A domain model should depend on nothing externally, except via interfaces which are a part of the domain model. The real tl;dr is that if you can't run and test your domain model without a database, UI, external services etc, it likely is not a domain model in the first place. Your misunderstanding is common when ignoring the provenance of the pattern: the place for it is "when you have complex and ever-changing business rules" (page 116 of Patterns of Enterprise Architecture). If "user.render(engine)" or "engine.render(user)" are operations in your domain model (and are, as I assume from your post, UI related operations) the domain model is being used as an architectural pattern rather than a business logic organization pattern, in which case none of the stated benefits hold because of misuse.

by daxfohl 11y ago

anthony_d 11y ago

The coupling you mention was solved long before DI became popular. The service locator pattern isn't as transparent as DI but it solves the problem of course grained service dependencies.

facorreia 11y ago
You mean "coarse-grained", right?

jen20 11y ago

This is a gross misunderstanding of a rich domain model. A domain model should depend on nothing externally, except via interfaces which are a part of the domain model. The real tl;dr is that if you can't run and test your domain model without a database, UI, external services etc, it likely is not a domain model in the first place. Your misunderstanding is common when ignoring the provenance of the pattern: the place for it is "when you have complex and ever-changing business rules" (page 116 of Patterns of Enterprise Architecture). If "user.render(engine)" or "engine.render(user)" are operations in your domain model (and are, as I assume from your post, UI related operations) the domain model is being used as an architectural pattern rather than a business logic organization pattern, in which case none of the stated benefits hold because of misuse.