> Markdown version of [/videos/411-it-s-all-about-the-domain-honey-experiences-from-15-years-of-domain-driven-design?t=14](https://www.wearedevelopers.com/videos/411-it-s-all-about-the-domain-honey-experiences-from-15-years-of-domain-driven-design?t=14). 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). --- # It’s all about the domain, honey ! Experiences from 15 years of Domain-Driven Design Are your microservices just a poorly managed distributed monolith? Discover why fifteen years of Domain-Driven Design proves that intentional boundaries are the true key to sustainable software architecture. - **Speakers:** [Carola Lilienthal](https://www.wearedevelopers.com/@carola-lilienthal) - **Event:** World Congress 2022 - **Published:** June 15, 2022 - **Duration:** 43:13 - **URL:** https://www.wearedevelopers.com/videos/411-it-s-all-about-the-domain-honey-experiences-from-15-years-of-domain-driven-design ## Summary Software systems naturally degrade over time, often devolving into a tangled big ball of mud where tightly coupled dependencies halt feature delivery. Transitioning to microservices does not automatically solve this structural decay; without proper modularity, teams simply create a harder-to-manage distributed monolith. The foundation of sustainable software architecture requires strict dependency control, focusing on high cohesion within modules and loose coupling between them. Domain-Driven Design (DDD) offers a strategic path forward by aligning software architecture directly with business realities. Using discovery frameworks like event storming and domain storytelling, architects can pinpoint where information uniquely flows in a business process and segment systems accordingly. Instead of organizing services around shared entities—which forces tight technical coupling—development should revolve around bounded contexts modeled after distinct business capabilities, such as separating high-level cinema management from real-time ticket sales. A major conceptual hurdle for developers is accepting that domain models should deliberately overlap across boundaries. Maintaining tailored, context-specific variations of a simple concept like a schedule provides vastly superior isolation compared to maintaining a single, sprawling enterprise model. When starting new projects, establishing a well-structured monolith establishes the necessary domain boundaries so teams can safely discover intricacies before extracting microservices. This intentional approach ensures scalable, asynchronous communication via events and sustains a codebase equipped to survive ongoing business changes. **Keywords:** domain-driven design, strategic design, bounded contexts, sustainable software architecture, legacy system refactoring, software modularity management, microservices migration challenges, distributed big ball of mud, high cohesion loose coupling, event storming, domain storytelling, modularity maturity index, monolithic architecture design, bounded context communication, event-driven architecture integration ## Chapters 1. **Building and maintaining sustainable software architectures** (00:14) — Maintaining a steady stream of feature delivery over multiple releases requires continuous attention to structural health and refactoring. 1. **Microservices and the distributed big ball of mud** (07:20) — Cutting a highly coupled monolith into networked pieces fails unless internal modularity and dependencies are properly resolved beforehand. 1. **Designing for high cohesion and loose coupling** (11:01) — Dependency control forms the core of sustainable design by defining a clear separation of concerns within and across modules. 1. **Resolving entangled domain models in legacy applications** (12:51) — Grouping software by use cases instead of business capabilities often results in deeply tangled core domain classes. 1. **Defining subdomains and bounded contexts in software** (17:59) — Strategic design sets explicit boundaries around small domain components to isolate requirements and empower independent engineering teams. 1. **Using domain storytelling to discover architectural boundaries** (21:09) — Recognizing distinct business triggers and one-way information flows helps locate natural architectural cuts in complex organizational workflows. 1. **Implementing distinct domain boundaries without tight coupling** (25:44) — Restricting module communication to asynchronous updates prevents the operational tight coupling caused by shared synchronous entity services. 1. **Evaluating codebases using the Modularity Maturity Index** (31:21) — Quantifying code structure provides an objective metric for evaluating how effectively an application separates independent business concepts. 1. **Managing domain duplication and evolving early architectures** (35:49) — Starting projects as well-structured monoliths allows domains to mature before teams implement complex microservices or event-driven communication layers. ## Related Moments - [Overview of domain-driven design techniques](https://www.wearedevelopers.com/videos/1571-20-years-of-domain-driven-design-what-i-ve-learned-about-ddd) (from "20 Years of Domain-Driven Design: What I’ve Learned About DDD") - [Structuring engineering teams around domain bounded contexts](https://www.wearedevelopers.com/videos/64-shared-mobility-for-everyone) (from "Shared mobility for everyone!") - [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") - [Restructuring the monolith using domain-driven design](https://www.wearedevelopers.com/videos/1206-single-server-global-reach-running-a-worldwide-marketplace-on-bare-metal-in-a-cloud-dominated-world) (from "Single Server, Global Reach: Running a Worldwide Marketplace on Bare Metal in a Cloud-Dominated World") - [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) - [Why You Shouldn’t Build a Microservice Architecture](https://www.wearedevelopers.com/magazine/118-why-you-shouldn-t-build-a-microservice-architecture) - [Are design and development really just the same thing?](https://www.wearedevelopers.com/magazine/520-are-design-and-development-really-just-the-same-thing) - [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering) ## 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** - [Software Solution Architekt](https://www.wearedevelopers.com/jobs/ext/1458613-software-solution-architekt) at **BWI GmbH** - [Principal Software Engineer, Database Infrastructure](https://www.wearedevelopers.com/jobs/ext/1465908-principal-software-engineer-database-infrastructure) at **GitHub** - [Senior Data Engineer](https://www.wearedevelopers.com/jobs/ext/1589390-senior-data-engineer) at **Douglas GmbH** - [Backend Entwickler C#/.NET iv.)](https://www.wearedevelopers.com/jobs/ext/1262419-backend-entwickler-c-net-iv) at **Bosch-Gruppe Österreich** - [Senior Cloud Software Architect (all genders welcome) for our Intelligent Service Operations Hub](https://www.wearedevelopers.com/jobs/ext/1284556-senior-cloud-software-architect-all-genders-welcome-for-our-intelligent-service-operations-hub) at **Rosenxt Group**