"... the key to expert performance in many fields
is domain knowledge rather than intelligence."
Domain Driven Design
is a software development methodology, intended to achieve a software system
closely modelled on and aligned with real business processes.
development tends to be a technically led process, where requirements are
passed from the business to the development teams, and then the development
teams go off and produce their best guesstimate at what the requirements said.
In a waterfall
approach this leads to large requirements documents that are diligently
collated, analysed, reviewed and approved. These documents are then given to
development teams to turn into working software.
Agile approaches can
also accept the requirements documents that waterfall tends to produce, but for
them to actually progress forwards they must be broken to small tasks and
stories which can then be queued ready for development.
Domain Driven Design
to a large degree steps back from these two distinct ends of the spectrum, and
looks at how the requirements are gathered in the first place - if you like, it
bridges the gap between doing everything up front and everything at the last
DDD understands that
requirements are never 'done', but exist as a living document. More
importantly, the living document in question is actually the software itself -
all other documents are an artefact and reflection of the code.
As the software
system develops and grows, deeper understanding of the problem grows too - DDD
is all about the discovery of the solution through deeper understanding of the
Where DDD really
differs though is that it sees the software system as a reflection of the
business process, an enabler rather than the driver. DDD is deeply concerned
about the business processes, business terminology and practices. Technical
concerns are largely secondary and a means to an end.
The Ubiquitous Language is at the centre of DDD - this is a shared and growing language. A
negotiated language derived from the business terminology and enriched by the development teams. If a business person doesn't understand a term in the UL,
then the chances are the UL needs an evolution. If a technical person doesn't
understand a term in the UL then the chances are they need a conversation with
a Domain Expert.
The Domain Experts
are the second essential component of DDD - people who deeply understand the
business domain, and the business itself. These people are integral to the
development process. They may not be required "full time" like the
traditional Product Owners of some Agile methodologies, but they must be
accessible continually, and be prepared to invest time in the process. Domain
Experts are not to be considered outsiders, but as the core of the DDD process
- they are as much a part of the development team as any developer or tester.
DDD doesn't begin
and end - it is a constant process of re-evaluation, refactoring, remodelling
and redesign - every conversation should bring you to a closer understanding of
the problem. At no point is DDD 'done' - it is always there; the Ubiquitous Language
grows and develops, the Domain Models change as understanding changes, code is
restructured and refactored to better represent that understanding.
Artefacts will come
and go, but only one really matters - the code base. It is the only expression
of the solution that is free of abstraction. While documents may try to explain
or describe the system, only the code does so without losing information. This
means that in DDD the code must remain of high quality, be clear and
expressive, be free of technical abbreviations or jargon, and as far as
possible should make at least some sense to a Domain Expert when explained to
Clever code doesn't
work in DDD, nor do magical processes or "you don't need to know"
components. Domain Experts shouldn't need to become developers to understand
what the key parts of the software system is doing for them. They also shouldn't need to think in terms of
databases or batch jobs or other technical concerns.
DDD is the ultimate
expression of Agile - it is about dealing with a constantly shifting and
evolving set of requirements - because as anyone who has ever been involved
with a software project knows - it is very rare for a requirement to remain
intact from the beginning to the end of a project, and almost impossible for it
to do so as the business grows and changes.
conversations, DDD will guide you to an ever more accurate software
representation of your business process.
05-16-2011 3:15 AM