O'Reilly logo
live online training icon Live Online training

Domain-Driven Design for Monoliths

Tackling complexity in the heart of legacy software

Topic: Software Development
Vladik Khononov

While domain-driven design (DDD) has proved itself as a powerful software design tool, it’s still underutilized. Many refrain from DDD thinking that it’s an all-or-nothing affair—either you implement every pattern the methodology has to offer, or you don’t do it all. Others miss strategic opportunities thinking that DDD can only be applied on greenfield projects. The truth is that not only can brownfield projects benefit from DDD, but often they desperately need it to solve the challenges in legacy systems.

For example, when documents are mostly outdated and business domain knowledge is spread across different stakeholders, cultivating a shared understanding of the business domain through event storming is an effective way to recover the knowledge. Building a context map makes it easy to spot sociotechnical design issues, while contexts integration patterns guide on how to improve these strategic decisions. Last but not least, with DDD’s subdomains, you can evaluate the project’s business logic implementation and spotlight the areas that need improvement or refactoring the most.

Join expert Vladik Khononov to learn how to apply DDD on brownfield projects—the type of projects we work on the most in real life. You’ll explore the strategic aspect of DDD and learn to selectively apply its patterns and practices to gain and recover domain knowledge, improve modularity, and, most importantly, continuously evolve design decisions aligning them with the software’s business strategy and goals.

What you'll learn-and how you can apply it

By the end of this live online course, you’ll understand:

  • The core principles, patterns, and practices of strategic domain-driven design
  • How to apply DDD on brownfield projects
  • Patterns for integrating components of a system

And you’ll be able to:

  • Analyze your business domain to better understand its goals, strategy, and priorities
  • Improve sociotechnical design decisions
  • Evolve software architecture to better fit business needs

This training course is for you because...

  • You’re a software engineer or an architect.
  • You work with brownfield projects.
  • You want to be effective by evolving architectural decisions of existing software systems.


  • A basic understanding of software and software design
  • Experience as an architect or working with an architect

Recommended preparation:

  • Read the introduction to What Is Domain-Driven Design? (book)

Recommended follow-up:

About your instructor

  • Vladik (Vlad) Khononov is a software engineer with over 15 years of industry experience, during which he has worked for companies large and small in roles ranging from webmaster to chief architect. Vlad is a long-time proponent of domain-driven design and evolutionary architecture and currently helps companies make sense of their business domains, untangle monoliths, and tackle complex architectural challenges.

    Vlad maintains an active media career as a public speaker and blogger. He has spoken at numerous industry conferences — including O’Reilly Software Architecture, DDD Europe, and NDC — about subjects such as domain-driven design, microservices, and software architecture in general. In addition to his media work, he co-organizes the Domain-Driven Design Israel and Tel Aviv Software Architecture meetup groups.

    Vladik lives in Northern Israel with his wife and an almost-reasonable number of cats.


The timeframes are only estimates and may vary according to how the class is progressing

Analyzing business domains (35 minutes)

  • Presentation: Analyzing business domains
  • Group discussion: The practical difference between core, supporting, and generic subdomains
  • Hands-on exercise: Identify the business domain and its subdomains in a case study
  • Q&A
  • Break (5 minutes)

Acquiring and modeling domain knowledge (50 minutes)

  • Presentation: Creating a shared understanding of the problem domain; modeling with bounded contexts
  • Group discussion: Possible difficulties in cultivating a ubiquitous language; bounded contexts’ size
  • Hands-on exercise: Improving the shared language; identify existing bounded contexts
  • Q&A
  • Break (5 minutes)

Integrating bounded contexts (45 minutes)

  • Presentation: Bounded contexts integration patterns; context mapping
  • Group discussion: Applicability contexts for integration patterns; evaluating strategic design decisions
  • Hands-on exercise: Identify existing integration patterns; analyze a context map

Evolving design decisions (40 minutes)

  • Presentation: Change factors affecting software design
  • Group discussion: Rethinking strategic design decisions
  • Hands-on exercise: Identify outdated design decisions
  • Q&A