Short review: Domain Driven Design
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:
- Cannot be used for implementation since implementation concerns not considered during construction,
- Knowledge gained during model creation is only partly captured in model, so is lost during transition to implementation,
- Crucial discoveries about domain occur when designing the implementation,
- With separate analysis and design models, a) modeling is less disciplined so less useful, b) designers may not get access to domain experts,
- (bold) Deadly divide occurs between analysis and design where insights in each do not feed back to the other.
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.
