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

If the people who write the code do not feel responsible for the model, or don't
understand how to make the model work for an application, then the model has nothing
to do with the software. If developers don't realize that changing code changes the
model, then their refactoring will weaken the model rather than strengthen it.
Meanwhile, when a modeler is separated from the implementation process, he or she
never acquires, or quickly loses, a feel for the constraints of implementation. The basic
constraint of 
MODEL-DRIVEN DESIGN
—that the model supports an effective
implementation and abstracts key domain knowledge—is half-gone, and the resulting
models will be impractical. Finally, the knowledge and skills of experienced designers
won't be transferred to other developers if the division of labor prevents the kind of
collaboration that conveys the subtleties of coding a 
MODEL-DRIVEN DESIGN
.
The need for 
HANDS-ON MODELERS
does not mean that team members cannot have specialized

---

roles. Every Agile process, including Extreme Programming, defines roles for team members, and
other informal specializations tend to emerge naturally. The problem arises from separating two
tasks that are coupled in a 
MODEL-DRIVEN DESIGN
, modeling and implementation.
The effectiveness of an overall design is very sensitive to the quality and consistency of fine-
grained design and implementation decisions. With a 
MODEL-DRIVEN DESIGN
, a portion of the code is
an expression of the model; changing that code changes the model. Programmers are modelers,
whether anyone likes it or not. So it is better to set up the project so that the programmers do
good modeling work.
Therefore: