> Markdown version of [/videos/1571-20-years-of-domain-driven-design-what-i-ve-learned-about-ddd?t=6](https://www.wearedevelopers.com/videos/1571-20-years-of-domain-driven-design-what-i-ve-learned-about-ddd?t=6). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# 20 Years of Domain-Driven Design: What I’ve Learned About DDD

Software quality cannot be universally perfect. Discover how twenty years of Domain-Driven Design teaches engineering leaders to prioritize the core domain and organize architecture by functionality.

- **Speakers:** [Eberhard Wolff](https://www.wearedevelopers.com/@eberhard-wolff)
- **Event:** World Congress 2025
- **Published:** August 20, 2025
- **Duration:** 29:11
- **URL:** https://www.wearedevelopers.com/videos/1571-20-years-of-domain-driven-design-what-i-ve-learned-about-ddd

## Summary

Reflecting on two decades since Eric Evans introduced Domain-Driven Design (DDD), the methodology reveals itself to be far more holistic than a mere set of object-oriented coding rules. The core philosophy dictates that the domain must actively drive system architecture to deliver genuine customer value. A pivotal realization for engineering leaders is that software quality cannot be universally perfect across an entire system; instead, teams must deliberately prioritize the core domain rather than "letting that quality happen by chance." If a migration to a DDD architecture does not improve the user experience or provoke continuous conversations with users, the implementation has missed its fundamental purpose.

A crucial mechanism of DDD is "knowledge crunching," which bridges the natural knowledge gap between technical teams and business experts. Methodologies like collaborative modeling and event storming—famous for their informal mapping of past-tense verb events onto orange stickies—lower the barrier to entry, enabling cross-functional, parallel participation. Ultimately, the dynamic process of collaborative modeling and uncovering how teams interact holds significantly more value than the resulting architectural artifacts.

Architecturally, Bounded Contexts serve as a powerful pattern combining a ubiquitous language, a domain model, and a dedicated team. However, developers often fall into the trap of grouping software by "data modules" (such as creating global "Customer" or "Product" entities), which inevitably creates fragile cross-dependencies. To build truly scalable architecture, teams should organize by functionality to maintain high module autonomy. In an e-commerce system, for example, Invoicing, Shipping, and Ordering should operate as separate bounded contexts—each maintaining its own specialized, independent representation of what a "customer" or "product" means within that specific domain logic.

**Keywords:** domain-driven design, core domain prioritization, tactical design techniques, strategic design implementation, collaborative modeling, event storming process, knowledge crunching, bounded context autonomy, ubiquitous language, data module anti-pattern, software architecture strategy, business logic decoupling, domain expert collaboration, functional software modularity

## Chapters

1. **Overview of domain-driven design techniques** (00:06) — An introduction to various domain-driven design practices ranging from big picture event storming to tactical code-level design.
1. **Prioritizing system quality with the core domain** (02:01) — Deliberately prioritizing quality in the core domain prevents randomly distributed software quality and focuses effort on what matters most.
1. **Driving software design through customer value** (06:22) — Migrating to an architecture must generate tangible value by directly addressing customer needs and focusing on domain logic over mere code flexibility.
1. **Bridging the engineering gap through knowledge crunching** (10:39) — Effective software development requires engineers and domain experts to collaborate closely to translate complex business knowledge into code.
1. **Facilitating collaboration with event storming methods** (12:35) — Low-barrier collaborative modeling techniques uncover actionable team dynamics and domain insights rather than just producing static mapping artifacts.
1. **Focusing on autonomous models over data modules** (17:35) — Designing bounded contexts around specific business functionalities ensures high system autonomy compared to relying on generic data-centric modules.

## Related Moments

- [Structuring engineering teams around domain bounded contexts](https://www.wearedevelopers.com/videos/64-shared-mobility-for-everyone) (from "Shared mobility for everyone!")
- [Utilizing domain-driven design for effective data models](https://www.wearedevelopers.com/videos/19-building-high-performance-and-scalable-architectures-for-enterprises) (from "Building high performance and scalable architectures for enterprises")
- [Identifying bounded contexts using domain-driven design principles](https://www.wearedevelopers.com/videos/987-modulith-instead-of-monolith-pragmatically-towards-microservices) (from "Modulith Instead of Monolith - Pragmatically Towards Microservices")
- [Building disciplined domain models for event-driven systems](https://www.wearedevelopers.com/videos/163-cqrs-and-event-sourcing-without-the-pixie-dust) (from "CQRS and Event Sourcing without the pixie dust")
- [Building long-term Angular architectures with domain-driven design](https://www.wearedevelopers.com/videos/5-sustainable-angular-architectures-with-nx-and-strategic-design) (from "Sustainable Angular Architectures with Nx and Strategic Design")
- [Enforcing clean architecture principles through domain driven design](https://www.wearedevelopers.com/videos/1195-the-great-api-debate-rest-graphql-or-grpc) (from "The Great API Debate: REST, GraphQL, or gRPC?")

## Related Articles

- [Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)](https://www.wearedevelopers.com/magazine/745-why-event-driven-architecture-isn-t-about-speed-and-when-you-actually-need-it)
- [Are design and development really just the same thing?](https://www.wearedevelopers.com/magazine/520-are-design-and-development-really-just-the-same-thing)
- [Never delegate the understanding](https://www.wearedevelopers.com/magazine/749-never-delegate-the-understanding)
- [Why developer experience matters](https://www.wearedevelopers.com/magazine/514-why-developer-experience-matters)

## Related Jobs

- [Tribe Lead - ( Software) Engineering Centre of Excllence](https://www.wearedevelopers.com/jobs/ext/1475530-tribe-lead-software-engineering-centre-of-excllence) at **SD Worx**
- [Senior Data Engineer](https://www.wearedevelopers.com/jobs/ext/1589390-senior-data-engineer) at **Douglas GmbH**
- [Principal Software Engineer, Database Infrastructure](https://www.wearedevelopers.com/jobs/ext/1465908-principal-software-engineer-database-infrastructure) at **GitHub**
- [Principal Software Engineer, Enterprise AI Platform](https://www.wearedevelopers.com/jobs/ext/1467292-principal-software-engineer-enterprise-ai-platform) at **GitHub**
- [Principal Software Engineer, Identity](https://www.wearedevelopers.com/jobs/ext/1469181-principal-software-engineer-identity) at **GitHub**
- [Software Solution Architekt](https://www.wearedevelopers.com/jobs/ext/1458613-software-solution-architekt) at **BWI GmbH**