Eric Evans: Domain Driven Design
Author : Eric J. Evans
Publisher: Addison-Wesley Longman, Amsterdam; Edition: 1. A. (4. September 2003)
Eric Evans introduces a new approach to Software Modeling: Domain Driven Design (DDD). Just as the title says it deals with techniques and best practices for managing domain complexity. At the core of it lies the concept of “unavoidable complexity” that is, the complexity of the domain. It is all about creating a model of your domain in software that captures all the knowledge necessary to solve the problems the software is intended to.
Evans starts with describing the development process necessary to make this goal achievable. Knowledge Crunching is all about invoking the Domain Experts and making the Developers understand the Domain. A Ubiquitos Language with a sharp description of all its elements must evolve, to make communication efficient and less prone to errors. An agile, feedback driven process is necessary for Binding Model and Implementation that is, feeding back insight gained during model implementation into the modeling process.
This takes us to the next important concept: Insight. Insight describes the process at a human level. It is the core challenge of building software that is intended to solve real-world problems. Software Developers mustn’t be specialists – they need to be generalists: engineers. A good developer bridges the gap between technology and domain because he is an expert in both. Eric Evans acknowledges it is impossible to be an expert in every domain without having experience with it.He therfore appreciates Insight and advocates refining the model when new Insight is gained. Through continuous Knowledge Crunching and Distillation a Deep Model eventually emerges.
A process like this requires proactive structuring of the code base to accomodate change – Supple Design. Something which I think is a very essential concept. It is necessary for a Test Driven Design Process or in areas of the domain that are likely to evolve in the future. For this purpose he describes a set of patterns that help abstracting domain object responsibilities into explicit concepts, which is another core tenet of Supple Design: Making Implicit Concepts Explicit. This applies not only to the structure of the code base but also to the concepts of the domain.
Opinion and Conclusion:
I think this book is a must read for everyone that considers software development to be a craft. The parallels to engineering are astonishing. Eric Evans has a very explicit style of writing, which accounts a lot to the value of this book. The sharp definitions and clear distinctions make it possible to convey a lot of information in a very dense manner. I wonder if Evans is a mathematician 🙂
Links and Accompanying Books:
- Eric Evans: What I’ve learned about DDD since the book
- (Martin Fowler) Patterns of Enterprise Application Architecture