Domain-Driven Design: Tackling Complexity in the Heart of Software

Architecture teams must not siphon off all the best and brightest
Design at this level calls for sophistication that is probably in short supply. Managers tend to move
the most technically talented developers into architecture teams and infrastructure teams,
because they want to leverage the skills of these advanced designers. For their part, the
developers are attracted to the opportunity to have a broader impact or to work on "more
interesting" problems. And there is prestige attached to being a member of an elite team.
These forces often leave behind only the least technically sophisticated developers to actually build
applications. But building good applications takes design skill; this is a setup for failure. Even if a
strategy team creates a great strategic design, the application team won't have the design
sophistication to follow it.
Conversely, such teams almost never include the developer who perhaps has weaker design skills
but who has the most extensive experience in the domain. Strategic design is not a purely
technical task; cutting themselves off from developers with deep domain knowledge hobbles the
architects' efforts further. And domain experts are needed too.
It is essential to have strong designers on all application teams. It is essential to have domain
knowledge on any team attempting strategic design. It may simply be necessary to hire more
advanced designers. It may help to keep architecture teams part-time. I'm sure there are many
ways that work, but any effective strategy team has to have as a partner an effective application
team.
Strategic design requires minimalism and humility
Distillation and minimalism are essential to any good design work, but minimalism is even more
critical for strategic design. Even the slightest ill fit has a terrible potential for getting in the way.
Separate architecture teams have to be especially careful because they have less feel for the
obstacles they might be placing in front of application teams. At the same time, the architects'
enthusiasm for their primary responsibility makes them more likely to get carried away. I've seen
this phenomenon many times, and I've even done it. One good idea leads to another, and we end
up with an overbuilt architecture that is counterproductive.
Instead, we have to discipline ourselves to produce organizing principles and core models that are
pared down to contain nothing that does not significantly improve the clarity of the design. The
truth is, almost everything gets in the way of something, so each element had better be worth it.
Realizing that your best idea is likely to get in somebody's way takes humility.