So, the whole point is to keep your model tidy, small and clean. Most of the tactical DDD patterns serve the goal of keeping the domain model clean. Classes like Factories or Repositories, belong in the domain layer, have a well defined responsibility, but I think their overall purpose is to allow for the cleanest possible programming style in Entities and Value Objects, where most of the domain behavior is coded. In a certain way, the whole system of patterns is a sort of necessary scaffolding to allow the domain model to thrive. Patterns are not part of discussion with users and domain experts (this is pretty obvious, but ...zealots are zealots), they’re just part of the implementation. They allow the model to be technology independent, or decoupled from other portions of the application, they allow the model to be easily tested. They allow for complexity to be managed in an elegant and scalable way.
Sometimes elegance might be a problem
There is some aesthetic quality in a well crafted domain model. Some developers really like what a DDD model will look like. Guess what? I like it too. But that might deviate our attention to what really matters. Sometimes elegance has no business value, or better, is perceived to have none, by non-developers.
- “We’re refactoring this architecture to make it more elegant”
- “I don’t pay you to write Armani-dressed code! I want code that works and I want it fast!”
So if you’re enthusiastically embracing DDD and try to apply what you’ve read in the book, be careful not to transform yourself in a DDD pattern zealot. Their elegance might distract attention from the real goal: they’re helpful and often indispensable, but the real target is in the domain itself, and in it’s business value.