Short review: Domain Driven Design

Nov 26, 2007 | George Fairbanks

Book: "Domain Driven Design, Tackling Complexity at the Heart of Software":
By: Eric Evans
Publisher: Addison-Wesley, ISBN 0321125215

This is the only book I’ve seen that explains what good
object-oriented developers do when they incrementally discover a
domain by interviewing subject matter experts and building models. The
book uses fictitious dialogues between a developer and a SME, which
accurately capture the SME’s initial lack of confidence in the process
and the transition into trust and effective collaboration. The book
also documents a number of useful patterns.

However, it would have been a better book, a book with a wider
audience, if it had refrained from preaching about agile software
development. Or even if the book were organized around a series of
essays, and just one of the essays was about agile. But instead I
found myself arguing with the author when the commentary about
integrating modeling with code came up. This commentary didn’t have
the requisite “agile hedge” regarding “don’t try this at scale”.

I support integrating modeling and code when possible. But recently
I’ve been on too many projects with large scope (big NYC banks) and
non-technical subject matter experts. The book advocates models that
are just slightly more abstract than the code, but these would have
been rejected by the SMEs. There is a benefit to having models at
various levels of detail, though it introduces challenges with keeping
them updated and relevant. I would personally enjoy being on smaller
projects using XP or another agile method, but someone has to slay the
ugly dragons on large, brownfield projects.

Pages 47-49 contain a critique of analysis models, that is, those
models that aren’t directly represented in the code. The identified
problems with analysis models are: 1) Cannot be used for
implementation since implementation concerns not considered during
construction, 2) Knowledge gained during model creation is only partly
captured in model, so is lost during transition to implementation, 3)
Crucial discoveries about domain occur when designing the
implementation, 4) With separate analysis and design models, a)
modeling is less disciplined so less useful, b) designers may not get
access to domain experts, 6) (bold) Deadly divide occurs between
analysis and design where insights in each do not feed back to the

I’ve seen most of these problems in practice, so it’s good that they
are enumerated. Either you can avoid analysis models, or you can be
forewarned and forearmed.


George Fairbanks is a software developer, designer, and architect living in New York city

+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks