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

Objects are specialists; developers are generalists
The essence of good object design is to give each object a clear and narrow responsibility and to
reduce interdependence to an absolute minimum. Sometimes we try to make interactions on
teams as tidy as they should be in our software. A good project has lots of people sticking their
nose in other people's business. Developers play with frameworks. Architects write application
code. Everyone talks to everyone. It is efficiently chaotic. Make the objects into specialists; let the
developers be generalists.

---

Because I've made the distinction between 
strategic design
and other kinds of design to help
clarify the tasks involved, I must point out that having two kinds of design activity does not mean
having two kinds of people. Creating a supple design based on a deep model is an advanced
design activity, but the details are so important that it has to be done by someone working with
the code. Strategic design emerges out of application design, yet it requires a big-picture view of
activity, possibly spanning multiple teams. People love to find ways to chop up tasks so that design
experts don't have to know the business and domain experts don't have to understand technology.
There is a limit to how much an individual can learn, but overspecialization takes the steam out of
domain-driven design.
The Same Goes for the Technical Frameworks
Technical frameworks can greatly accelerate application development, including the domain layer,
by providing an infrastructure layer that frees the application from implementing basic services,
and by helping to isolate the domain from other concerns. But there is a risk that an architecture
can interfere with expressive implementations of the domain model and easy change
. This can
happen even when the framework designers had no intention of venturing into the domain or
application layers.
The same biases that limit the downside of strategic design can help with technical architecture.
Evolution, minimalism, and involvement with the application development team can lead to a
continuously refined set of services and rules that genuinely help application development without
getting in the way. Architectures that don't follow this path will either stifle the creativity of
application development or will find their architecture circumvented, leaving application
development, for practical purposes, with no architecture at all.
There is one particular attitude that will surely ruin a framework.