Eric Evans, Mr. Domain Driven Design

In the 5 years since the book was published, I've practiced DDD on various client projects, and I've continued to learn about what works, what doesn't work, and how to conceptualize and describe it all. Also, I've gained perspective and learned a great deal from the increasing number of expert practitioners of DDD who have emerged.

The fundamentals have held up well, as well as most patterns, but there are differences in how I do things and look at things now. I will try to describe them, very informally, in this talk.

Over this time, I have folded in a couple of additional patterns, and essentially come to ignore a few, but the biggest change has been a subtle shift of emphasis. Ubiquitous Language and Context Mapping and Core Domain are at the center, with aggregates in close orbit. Why, I ask myself, did I put context mapping in Chapter 14? Core domain in Chapter 15?! Before the book, it seemed self-evident to me that SOA fit well with DDD, but five years of questions on that topic have made it clear that my early explanations were inadequate and helped me clarify how it fits. Increased emphasis on events and distributed processing have crystallized the significance of aggregates and refined the building blocks.

The talk cannot go into depth on all these topics, but the goal will be to give a quick look at where my view of DDD has been heading.

As software development leaders, we need to think more strategically. Some design decisions affect the trajectory of the whole project or even the organization. These decisions arise in early chartering and throughout development, and they are about much more than architecture. This talk will examine these issues through the lens of the Strategic Design principles of domain-driven design, which systematize a few critical practices some successful teams do intuitively.

It is common for skilled teams to deliver software they are not proud of, due to compromises with legacy designs. Others toil for years, producing a platform that is never used to good advantage. These are strategic failures. On the other hand, there are projects with a direct explanation of how the software contributes to business goals. There are projects where designers work with a realistic view of the context of their development within the larger system, allowing them to maintain design clarity and integrity. These are strategic successes. Winning strategy starts with the domain.

Two domain-driven design principles, "Context Mapping" and "Distilling the Core Domain", help you see your strategic situation more clearly and approach strategic design decisions more systematically. These techniques require extensive interaction with domain experts as well as the leaders of the organization, in discussions broader than functional requirements. They sometimes lead to priorities quite different from our most comfortable notions.