DDD patterns as “elegant support”

I've got quite a challenging response to my article about context mapping on InfoQ, that forced me to re-think about the article, and re-express some concepts, because some statements could have been misleading. I quickly mentioned the “classical” or “tactical” DDD patterns, such as Aggregates and Repositories and it looked like they’re the key to successful design. Well, they do help a lot, but the key to successfully implement a domain model is to understand the domain, achieving a creative collaboration with the domain expert. Practically this produces a small, but sophisticated, domain model that deeply reflects our understanding of the domain and supports our future, business-driven, changes. It’s impressive to see how a well designed model can accommodate changes.

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!”

Has any of us developers being seduced by the beauty of numbers in an Excel balance sheet from the finance department? I guess not. It’s just a different language. So, sometimes it’s better to express “elegance” as “reducing the cost of change”. Sounds a lot more like business, and a lot less like a disconnected geek spending the time tidying up the code (by the way also cleanup doesn’t really work). We’ll still implement elegantly, but that’s our job.

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.