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

A Newly Planted Olive Grove
Until the domain-driven approach is more widespread, the interesting software on many projects

---

will be built in a short, highly productive interval. Eventually the project will transform into
something more conventional that may not be able to fully exploit, much less enhance, the power
of the deep models that were distilled earlier. I could wish for more, but truly those are successes
that deliver sustained value to users over many years.
On one project I paired with another developer to write a utility the customer needed to produce
its core product. The features were fairly complicated and combined in intricate ways. I enjoyed
the project work and we produced a supple design with an 
ABSTRACT CORE
. When this software was
handed off, that was the end of involvement for everyone who had initially developed it. Because it
was such an abrupt transition, I expected that the design features which supported the combinable
elements might be confusing and might get replaced by more typical case logic. This did not
initially happen. When we handed off, the package included a thorough test suite and a distillation
document. The new team members used that document to guide their explorations, and as they
looked into things, they became excited by the possibilities the design presented. When I heard
their comments a year later, I realized that the 
UBIQUITOUS LANGUAGE
had sparked across to the
other team and stayed alive, continuing to evolve.
Seven Years Later
Then, another year later, I heard a different story. The team had encountered new requirements
that the developers didn't see any way to accomplish within the inherited design. They had been
forced to change the design almost beyond recognition. As I probed for more details, I could see
that aspects of our model would have made solving those problems awkward. It is precisely during
such moments when a breakthrough to a deeper model is often possible, especially when, as in
this case, the developers had accumulated deep knowledge and experience in the domain. In fact,
they had had a rush of new insights and ended up transforming the model and design based on
those insights.
They told me this story carefully, diplomatically, expecting, I suppose, that I would be disappointed
by their discarding of so much of my work. I am not that sentimental about my designs. The
success of a design is not necessarily marked by its stasis. Take a system people depend on, make
it opaque, and it will live forever as untouchable legacy. A deep model allows clear vision that can
yield new insight, while a supple design facilitates ongoing change. The model they came up with
was deeper, better aligned with the real concerns of the users. Their design solved real problems.
It is the nature of software to change, and this program has continued to evolve in the hands of
the team that owns it.

---

The shipping examples scattered through the book are loosely based on a project for a major
international container-shipping company. Early on, the leadership of the project was committed
to a domain-driven approach, but they never produced a development culture that could fully
support it. Several teams with widely different levels of design skill and object experience set out
to create modules, loosely coordinated by informal cooperation between team leaders and by a
customer-focused architecture team. We did develop a reasonably deep model of the 
CORE DOMAIN
,
and there was a viable 
UBIQUITOUS LANGUAGE
.
But the company culture fiercely resisted iterative development, and we waited far too long to
push out a working internal release. Therefore, problems were exposed at a late stage, when they
were more risky and expensive to fix. At some point, we discovered specific aspects of the model
were causing performance problems in the database. A natural part of 
MODEL-DRIVEN DESIGN
is the
feedback from implementation problems to changes in the model, but by that time there was a
perception that we were too far down the road to change the fundamental model. Instead,
changes were made to the code to make it more efficient, and its connection to the model was
weakened. The initial release also exposed scaling limitations in the technical infrastructure that
threw a scare into management. Expertise was brought in to fix the infrastructure problems, and
the project bounced back. But the loop was never closed between implementation and domain
modeling.
A few teams delivered fine software with complex capabilities and expressive models. Others
delivered stiff software that reduced the model to data structures, though even they retained
traces of the 
UBIQUITOUS LANGUAGE
. Perhaps a 
CONTEXT MAP
would have helped us as much as
anything, as the relationship between the output of the various teams was haphazard. Yet that
CORE
model carried in the 
UBIQUITOUS LANGUAGE
did help the teams ultimately to glue together a
system.
Although reduced in scope, the project replaced several legacy systems. The whole was held
together by a shared set of concepts, though most of the design was not very supple. It has itself
largely fossilized into legacy now, years later, but it still serves the global business 24 hours a day.
Although the more successful teams' influence gradually spread, time runs out eventually, even in
the richest company. The culture of the project never really absorbed 
MODEL-DRIVEN DESIGN
. New
development today is on different platforms and is only indirectly influenced by the work we
did—as the new developers 
CONFORM
to their legacy.
In some circles, ambitious goals like those the shipping company initially set have been
discredited. Better, it seems, to make little applications we know how to deliver. Better to stick to
the lowest common denominator of design to do simple things. This conservative approach has its
place, and allows for neatly scoped, quick-response projects. But integrated, model-driven
systems promise value that those patchworks can't. There is a third way. Domain-driven design
allows piecemeal growth of big systems with rich functionality, by building on a deep model and
supple design.
I'll close this list with Evant, a company that develops inventory management software, where I
played a secondary supporting role and contributed to an already strong design culture. Others
have written about this project as a poster child of Extreme Programming, but what is not usually
remarked upon is that the project was intensely domain-driven. Ever deeper models were distilled
and expressed in ever more supple designs. This project thrived until the "dot com" crash of 2001.
Then, starved for investment funds, the company contracted, software development went mostly
dormant, and it seemed that the end was near. But in the summer of 2002, Evant was approached
by one of the top ten retailers in the world. This potential client liked the product, but it needed
design changes to allow the application to scale up for an enormous inventory planning operation.
It was Evant's last chance.
Although reduced to four developers, the team had assets. They were skilled, with knowledge of
the domain, and one member had expertise in scaling issues. They had a very effective
development culture. And they had a code base with a supple design that facilitated change. That

---

summer, those four developers made a heroic development effort resulting in the ability to handle
billions of planning elements and hundreds of users. On the strength of those capabilities, Evant
won the behemoth client and, soon after, was bought by another company that wanted to
leverage their software and their proven ability to accommodate new demands.
The domain-driven design culture (as well as the Extreme Programming culture) survived the
transition and was revitalized. Today, the model and design continue to evolve, far richer and
suppler two years later than when I made my contribution. And rather than being assimilated into
the purchasing company, the members of the Evant team seem to be inspiring the company's
existing project teams to follow their lead. This story isn't over yet.
No project will ever employ every technique in this book. Even so, any project committed to
domain-driven design will be recognizable in a few ways. The defining characteristic is a priority on
understanding the target domain and incorporating that understanding into the software.
Everything else flows from that premise. Team members are conscious of the use of language on
the project and cultivate its refinement. They are hard to satisfy with the quality of the domain
model, because they keep learning more about the domain. They see continuous refinement as an
opportunity and an ill-fitting model as a risk. They take design skill seriously because it isn't easy
to develop production-quality software that clearly reflects the domain model. They stumble over
obstacles, but they hold on to their principles as they pick themselves up and continue forward.
[ Team LiB ]

---

[ Team LiB ]