Review By: Mark Entner
06/01/2007This book helps you to develop a domain model--a representation of the business, stated in business language--for complex software projects. Because the domain model is stated in business language, it forms a “ubiquitous language” that can be used by both the business and technical teams to discuss the project.

The author stresses that a domain model must be created as part of an iterative process. The model will evolve as additional knowledge is gained about the business area. As developers write code based on the model, and as discussions with the business users continue, new realizations will arise. It is important that the model continue to reflect the current understanding of the project. Otherwise, the model will quickly become outdated and useless to the project.

The book starts with a discussion of the goals of domain-driven design, including processing knowledge, enhanced communication, and binding the model to the implementation. It then progresses to the fundamental elements that make up the domain model and how to identify them. The importance of refactoring the model is discussed and how effective refactoring can make the model even easier to refactor in the future. Finally, the author discusses options for maintaining the focus on the core elements in a large system design.

The author conceptualizes his points with numerous illustrations drawn from his years of experience as a designer and programmer on large object-oriented systems. These concrete illustrations make the concepts accessible, showing how the concept can be applied to a real-life project.

For instance, one of the common issues that arise on a development project (or at least on the ones that I've worked on) is that different people in the business area can use the same term to mean different things. As the team constructs the model, it will become clear that each business person has a different set of properties and/or behaviors that they think the object should have. After a few iterations, the team will find that they really have two objects with the same name. The team can then correct the model and update the language that they use. In the future, the team will be clear on which object is being discussed.

Whether you are just starting with domain-driven design or have implemented many systems using it, you'll find value in this book. The author has spent many years applying these principles and is not an "ivory tower" architect. His background includes programming, and his experience has allowed him to create a modeling process that works for everyone on the project—users, software architects, developers, and even managers.