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:

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.