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

Hands-On Modelers
Manufacturing is a popular metaphor for software development. One inference from this
metaphor: highly skilled engineers design; less skilled laborers assemble the products. This
metaphor has messed up a lot of projects for one simple reason—software development is 
all
design. All teams have specialized roles for members, but overseparation of responsibility for
analysis, modeling, design, and programming interferes with 
MODEL-DRIVEN DESIGN
.
On one project, my job was to coordinate different application teams and help develop the domain
model that would drive the design. But the management thought that modelers should be
modeling, and that coding was a waste of those skills, so I was in effect forbidden to program or
work on details with programmers.
Things seemed to be OK for a while. Working with domain experts and the development leads of
the different teams, we crunched knowledge and refined a nice core model. But that model was
never put to work, for two reasons.
First, some of the model's intent was lost in the handoff. The overall effect of a model can be very
sensitive to details (as will be discussed in Parts II and III), and those details don't always come
across in a UML diagram or a general discussion. If I could have rolled up my sleeves and worked
with the other developers directly, providing some code to follow as examples, and providing some
close support, the team could have taken up the abstractions of the model and run with them.
The other problem was the indirectness of feedback from the interaction of the model with the
implementation and the technology. For example, certain aspects of the model turned out to be
wildly in-efficient on our technology platform, but the full implications didn't trickle back to me for
months. Relatively minor changes could have fixed the problem, but by then it didn't matter. The
developers were well on their way to writing software that did work—without the model, which had
been reduced to a mere data structure, wherever it was still used at all. The developers had
thrown the baby out with the bathwater, but what choice did they have? They could no longer risk
being saddled with the dictates of the architect in the ivory tower.
The initial circumstances of this project were about as favorable to a hands-off modeler as they
ever are. I already had extensive hands-on experience with most of the technology used on the
project. I had even led a small development team on the same project before my role changed, so
I was familiar with the project's development process and programming environment. Even those
factors were not enough to make me effective, given the separation of modeler from
implementation.