Bounded contexts in DDD provide clear boundaries within which specific domain models are defined and applicable, ensuring consistency and reducing ambiguity. By segregating the system into distinct contexts, it becomes easier to manage complexity, avoid model conflicts, and foster focused, autonomous development teams. Furthermore, bounded contexts facilitate better alignment between the software’s design and the organization’s actual business domains, enhancing clarity and communication.
In order to obtain a good understanding of the domain, and identifying bounded contexts, we will use a variety of methods as outlined below. Their combination gives us a good overview of the overall domain(s), and how we can split it (or them) into bounded contexts. Most of the methods outlined here are taken from the DDD Starter Modelling Process.
EventStorming is a method to identify the domain model of a system via its domain events. In the Big Picture workshop, you usually end up with a lot of domain events ordered into a rough timeline, separated by pivotal events. The pivotal events mark “important” points in time, where something significant happens in the domain. These pivotal events are a good starting point to identify bounded contexts, as they often mark the boundaries between them.
In addition, the Brandolini book (p. 133ff) provides a number of heuristics to identify bounded contexts from the event storming results, if the pivotal events are not sufficient to identify them. Two of these heuristics are summarized by the following quotes (Brandolini assumes a conference management system as an example domain):
Heuristic: look at the business phases … or like detectives would say: “follow the money!” Businesses grow around a well-defined business transaction where some value — usually money — is traded for something else. Pivotal events have a fundamental role in this flow: we won’t be able to sell tickets online without a website, every thing that happens before the website goes live is inventory or expenses, we can start making money only after the Conference Website Launched event.Similarly, after Ticket Sold events, we’ll be the temporary owners of attendees’ money, but they’ll start to get some value back only around the Conference Started event. But the tools and the mental models needed to design a conference, are not the same tools needed to run a conference.
Heuristic: look at the people on the paper roll. An interesting twist might happen when dealing with different personas. Apparently, the flow should be the same, but it’s not. Conference organizers or track hosts can invite some speakers, while others submit their proposals in the Call for Papers. The flows can be independent in the upstream part of the flow (you may want to skip a cumbersome review process for a superstar speaker). Downstream they’re probably not (on the conference schedule, you want the same data, regardless of how you got it).
In Domain-Driven Design (DDD), Core Domains, Supporting Domains, and Generic Domains are used to categorize different parts of a business. See DDD Glossary for a more detailed definition.
Core Domain Charts are a tool to classify (sub-)domains into these three categories.
(c) DDD Crew, https://github.com/ddd-crew/core-domain-charts
Core Domain Charts help you to visualise the strategic importance of each (sub)domain or business capability in your architecture allowing you to make business model-aligned architectural decisions.
A good source for further and in-depth information is [Tune, 2020].
The notation allows you to differentiate between commands, events, and queries, and to specify the payloads of these messages. In addition, it allows you to specify the direction of the message flow, and the order of their execution. It can be seen as an informal (or “less formal”) kind of flow diagram, depicting data / control flow in between bounded contexts and (external) systems.
The method is best described in a dedicated repo by the DDD Crew https://github.com/ddd-crew/domain-message-flow-modelling.
The bounded context canvas (https://github.com/ddd-crew/bounded-context-canvas) helps to sum up the constituents of a bounded context in somewhat standardized, compact form.
(c) DDD Crew, https://github.com/ddd-crew/bounded-context-canvas
DDD’s strategic design goes on to describe a variety of ways that you have relationships between Bounded Contexts. It’s usually worthwhile to depict these using a context map.
(Martin Fowler in his very instructive post on bounded contexts). Or, as Vaugn Vernon writes in the “red book” (p. 87):
The Context Map […] is […] a simple diagram that shows the mappings between two or more existing Bounded Contexts.
A great explanation of what context maps are can be found in Michael Plöd’s speakerdeck about them In addition, there is an extensive slide deck of my own, however still in German, as I haven’t translated it yet.
The DDD crew provides detailed material about context mapping. We will use their notation. However, for clarity we will combine this notation with Martin Fowler’s idea to draw the relationship pattern between aggregates, not whole bounded contexts. So it will be a combination of these two:
(c) DDD Crew, https://github.com/ddd-crew/context-mapping)
(c) Martin Fowler, https://martinfowler.com/bliki/BoundedContext.html
This section contains advice for student teams responsible for this topic in the DDD course.
The moderators as well as the participants require some familiarity with the methods. Therefore,
you first need to prepare a trial workshop with the other course members. This trial should be followed by a retrospective, where you analyse what went well and what could be improved. Before that trial workshop, you need to do the following:
In the DDD commented literature list, there is a dedicated “Modelling DDD” sources list - please go through it.