Bounded Context

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.

• Method Descriptions
  • Identify Bounded Context Boundaries from EventStorming Results
  • Core Domain Charts
  • Domain Message Flow Modelling
  • Bounded Context Canvas
  • Context Map
• Central DDD Concepts
• How to tackle this in an Academic Course
• Sources

Method Descriptions

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.

Identify Bounded Context Boundaries from EventStorming Results

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.

[Brandolini 2021, p. 133]

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).

[Brandolini 2021, p. 137]

Core Domain Charts

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.

[DDD Crew, Core Domain Charts, 2023]

A good source for further and in-depth information is [Tune, 2020].

Domain Message Flow Modelling

Domain Message Flow Modeling is a technique used in domain-driven design (DDD) to understand and visualize the flow of messages and domain events between bounded contexts.

(c) DDD Crew, https://github.com/ddd-crew/domain-message-flow-modelling

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.

Bounded Context Canvas

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

Context Map

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

Central DDD Concepts

• Domain
• Sub-Domain
• Bounded Context
• Context Map

How to tackle this in an Academic Course

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:

1. Use the domain from the EventStorming workshop as a starting point.
2. Familiarize yourself with the available sources on methods summed up under this term “Bounded Context Workshop” (see above).
3. Look at the results from that EventStorming workshop, to understand where you stand, and where you start from. You can assume that we hang up the EventStorming results again, physically in the room.
4. Fully understand the central DDD concepts listed above, and prepare to explain them to the other course members.
5. Write a workshop concept where you define how you want to run the workshop. Be aware that you have limited time, so you need to discuss how much time you want to dedicate to each part of it. You need to run the trial workshop in a timeboxed fashion - everything needs to be covered until end of the workshop, there is no “homework” for the participants. (This will be different for the case study workshop, where the participants can finish their work offline, after the workshop.)
6. Plan and conduct the trial workshop with the other course members. Decide wether you want to run it in a physical or virtual setting. Watch out: Physical workshops are more fun, but require more preparation and a lot more post-work (for capturing the results). So Miro might be a good choice for a digital trial workshop.
7. The other course members need be familiar with the central DDD concepts listed above before the workshop. You need to make sure they understand these concepts (how do you do that?).
8. Plan, conduct, and document a retrospective with the other course members. The goal is to identify what went well and what could be improved. The results of the retrospective need to be included in your final paper.
9. Document the trial workshop results, also to be included in your final paper. Think about an appropriate documentation format.
10. Plan, conduct, analyse, and document the case study workshop based on your experience from the trial.
11. Write chapters in your final paper that describes your workshop concept, the trial workshop, the retrospective, and the trial workshop results. The paper should be written in a way that it can be used as a guide for other course members who want to conduct workshop like this.

Sources

In the DDD commented literature list, there is a dedicated “Modelling DDD” sources list - please go through it.