Domain-Driven Design by Eric Evans, ISBN 0321125215

Reviewed by: Howard Carson, January 2005, send e-mail Published by: Addison Wesley Professional, go to the web site Requires: N/A MSRP: US$49.99, CAN$75.99 A serious title this is. The fundamental issues at the heart of software design are shifting with every new technology implementation. As Tom Kappel suggested in his Kickstartnews review of Agile Project Management: Creating Innovative Products the basic assumptions on which many new software projects are founded sometimes look more like shifting sand than solid ground. So too with rational domain-driven models in the realm of original software design. Software developers have the ability to express rich functionality and translate it into a program that directly serves the needs of the end users for which its intended. It's a laudable goal certainly, and one which is achieved far too infrequently. That's what Domain-Driven Design is all about. Domain modeling is one of the fundaments of software design these days. In fact, Object-Oriented Programming (OOP) is at the core of most of the domain modeling used on a daily basis on every platform. But the essence of successful domain modeling and domain-driven design is by definition embedded in the experiences of end users, not the theoretical or empiric estimates of engineers. What that means for software companies is simply that without effective end user research and focus group studies, and without seriously robust databases containing reports from end users about flaws (or at least perceived flaws) in software, domain-driven design often becomes something more akin to witchcraft than intelligent and thoughtful planning meant to truly encompass the needs of end users. The foregoing mouthful is brought to you by someone who has lived successfully on both sides of the software design fence. Too often, OOP and its necessary tangents, user interface engines, rendering engines and other things which pre-exist in any established software company's inventory get short shrift during the planning of new products and new versions of existing products. Without project management essentials such as peer review of code, general standards for coding and development and a variety of other rules, programmers may wander in all sorts of directions and into all sorts of trouble. Eric Evans' Domain-Driven Design is written to provide a structured set of ineluctable reminders about all the things needed to make domain-driven OOP worthwhile and powerful.

Evans is no rookie and it shows. His basic demand that all programmers need to buy into the common ground of the lifecycle of domain objects, the need for a plan to write combinable code at every legitimate opportunity, the application of analysis patterns, the need for all programmers to be speaking the same planning and coding language, and finding ways of creating predictability within the confines of complex code is an important lesson. It's also a demand that is lost on even the most experienced programmers too often these days. They tend to forget or at least lose sight of 'the rules' while they're working in highly pressurized development environments. Shortcuts abound, and individual programmers are left to fend for themselves too often as well, even when working on elements which will materially affect security and stability in the final version of the software. Is this sort of weak point in the design and project planning processes one of the reasons that Microsoft products have invited such an incredible onslaught of security breaches and attacks? Would longer product lifecycles built on slightly longer domain-driven design mandates make Microsoft products temporarily less competitive but more reliable and secure? And would greater reliability and security eventually make Microsoft products more competitive and more trusted?

My own experience with complex, non-Microsoft development projects is that more often than not any failure to build into the project the flexibility needed to accommodate dynamic changes is usually the weakest link in the chain. The moment that a product manager comes up in mid-project with a new feature or function that suddenly must be present in order to compete effectively in the marketplace, the design and planning of the entire project is sorely tested. Truly comprehensive project management combined with thorough domain-driven design should unite in such situations to effectively meet that product manager's legitimate needs without unduly stressing everyone into massive coronaries. Forget about enormous entities like Microsoft for a moment because this lesson applies to almost every software company out there.

All of the 'lessons' in the book come at a price which many software developers believe they cannot afford. At the end (of any development project) though, the advantages of coming to market on time with a robust and stable product after a slightly longer development cycle almost always outweigh the ephemeral advantage of arriving in the market early with a buggy pile of code. For example, hardware OEMs want to bundle the most stable and consistently reliable software, not the most feature-ridden less stable versions. Eric Evans seems to also understand that hard-driven programmers who have burned through bad planning, code objects that are nowhere near as versatile as they should be, and endless rounds of bug fixing aren't going to hang around for the next crusade driven by yet more shortsighted and inflexible product and development planning.

Evans stresses directly and by implication that all design must be driven by a clear understanding about how the completed software project will be applied by end users. To my way of thinking, any software architect who truly understands the most common range of end user needs and the potential changes or evolution in those needs, is by implication solidly in touch with the product's lifecycle and, by direct association, domain object lifecycles as well. That knowledge, along with the market realities imposed on the project manager and product manager, provides a secure framework in which domain-driven design can effectively take place. That's what Evans deals with and that's why this book is a good read.

Cons: Although it's readily apparent that Evans directs the book well and has really written it for programmers, Addison Wesley Professional should also be marketing the book at project and product managers.

Pros: Aside from his technical, planning and design skills, Eric Evans can write. The book is well organized, with clear statements of intent, practical and theoretical result comparisons, practical and metaphorical illustrations and examples, and lots and lots of code. Seat-of-the-pants programming is acknowledged as a necessary evil but Evans clearly demonstrates the situations in which even high-speed, short-term projects benefit from at least a few moments of careful domain-driven design. For programmers, project managers, software architects, planners and product managers, this book is a must-read. Every member of your development team, including the project and product managers, will benefit from reading some part of the book. Highly recommended.

Letters to the Editor are welcome and occasionally abused in public. Send e-mail to: whine@kickstartnews.com