Evans Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software

Addison Wesley, 2015. — 560 p. — ISBN: 978-0-321-12521-5.Eric Evans has written a fantastic book on how you can make the design of your software match your mental model of the problem domain you are addressing His book is very compatible with XP It is not about drawing pictures of a domain it is about how you think of it the language you use to talk about it and how you organize your software to reflect your improving understanding of it Eric thinks that learning about your problem domain is as likely to happen at the end of your project as at the beginning and so refactoring is a big part of his technique The book is a fun read Eric has lots of interesting stories and he has a way with words I see this book as essential reading for software developers it is a future classic Ralph Johnson author of Design Patterns If you don t think you are getting value from your investment in object oriented programming this book will tell you what you ve forgotten to do Eric Evans convincingly argues for the importance of domain modeling as the central focus of development and provides a solid framework and set of techniques for accomplishing it This is timeless wisdom and will hold up long after the methodologies du jour have gone out of fashion Dave Collins author of Designing Object Oriented User Interfaces Eric weaves real world experience modeling and building business applications into a practical useful book Written from the perspective of a trusted practitioner Eric s descriptions of ubiquitous language the benefits of sharing models with users object life cycle management logical and physical application structuring and the process and results of deep refactoring are major contributions to our field Luke Hohmann author of Beyond Software Architecture This book belongs on the shelf of every thoughtful software developer Kent Beck What Eric has managed to capture is a part of the design process that experienced object designers have always used but that we have beenThe Structure of This Book
The book is divided into four major sections:
Part I: Putting the Domain Model to Work presents the basic goals of domain-driven development; these goals motivate the practices in later sections. Because there are so many approaches to software development, Part I defines terms and gives an overview of the implications of using the domain model to drive communication and design.Part II: The Building Blocks of a Model-Driven Design condenses a core of best practices in object-oriented domain modeling into a set of basic building blocks. This section focuses on bridging the gap between models and practical, running software. Sharing these standard patterns brings order to the design. Team members more easily understand each other’s work. Using standard patterns also contributes terminology to a common language, which all team members can use to discuss model and design decisions.But the main point of this section is to focus on the kinds of decisions that keep the model and implementation aligned with each other, each reinforcing the other’s effectiveness. This alignment requires attention to the detail of individual elements.
Careful crafting at this small scale gives developers a steady foundation from which to apply the modeling approaches of Parts III
and IV.Part III: Refactoring Toward Deeper Insight goes beyond the building blocks to the challenge of assembling them into practical models that provide the payoff. Rather than jumping directly into esoteric design principles, this section emphasizes the discovery process. Valuable models do not emerge immediately; they require a deep understanding of the domain. That understanding comes from diving in, implementing an initial designbased on a probably naive model, and then transforming it again and again. Each time the team gains insight, the model is transformed to reveal that richer knowledge, and the code is refactored to reflect the deeper model and make its potential available to the application. Then, once in a while, this onion peeling leads to an opportunity to break through to a much deeper model, attended by a rush of profound design changes.Exploration is inherently open-ended, but it does not have to be random. Part III delves into modeling principles that can guide choices along the way, and techniques that help direct the search.Part IV: Strategic Design deals with situations that arise in complex systems, larger organizations, and interactions with external systems and legacy systems. This section explores a triad of principles that apply to the system as a whole: context, distillation, and large-scale structure. Strategic design decisions are made by teams, or even among teams. Strategic design enables the goals of Part I to be realized on a larger scale, for a big system or an application that fits into a sprawling, enterprise-wide network.
Throughout the book, discussions are illustrated not with oversimplified, “toy” problems, but with realistic examples adapted from actual projects.Much of the book is written as a set of “patterns.” Readers should be able to understand the material without concern about this device, but those who are interested in the style and format of the patterns may want to read the appendix.