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

Figure 16.1. Some patterns of large-scale structure
[ Team LiB ]

---

[ Team LiB ]
Evolving Order
Many developers have experienced the cost of an unstructured design. To avoid anarchy, projects
impose architectures that constrain development in various ways. Some technical architectures do
solve technical problems, such as networking or data persistence, but when architectures start
venturing into the arena of the application and domain model, they can create problems of their
own. They often prevent the developers from creating designs and models that work well for the
specifics of the problem. The most ambitious ones can even take away from application developers
the familiarity and technical power of the programming language itself. And whether technical or
domain oriented, architectures that freeze a lot of up-front design decisions can become a
straitjacket as requirements change and as understanding deepens.
While some technical architectures (such as J2EE) have become prominent over the years, large-
scale structure in the domain layer has not been explored much. Needs vary widely from one
application to the next.
An up-front imposition of a large-scale structure is likely to be costly. As development proceeds,
you will almost certainly find a more suitable structure, and you may even find that the prescribed
structure is prohibiting you from taking a design route that would greatly clarify or simplify the
application. You may be able to use some of the structure, but you're forgoing opportunities. Your
work slows down as you try workarounds or try to negotiate with the architects. But your
managers think the architecture is done. It was supposed to make this application easy, so why
aren't you working on the application instead of dealing with all these architecture problems? The
managers and architecture teams may even be open to input, but if each change is a heroic battle,
it is too exhausting.