Get best of the week

Designing a bounded context with a Bounded Context Canvas: workshop recipe

Among the topics of the upcoming TechLead Conf 2020 conference will be a detailed discussion of Domain-Driven Design and EventStorming. In addition to preparing a 2-slot report by Konstantin Gustov on DDD , a report by Sergey Baranov on EventStorming, and a mitap during which we will create a DDD radar, we decided to translate an article about one of the most popular methods for designing bounded context.

How to break a large system into smaller, more manageable components? I am often asked this question, so I gathered my knowledge in this article.

In DDD, a large system is decomposed into limited contexts (comment by a translator: hereinafter they will be referred to as bounded contexts) , which become natural boundaries - like microservices in code and as teams in an organization.

There is no way to quickly and easily determine the good boundaries of a bounded context. This requires extensive and in-depth knowledge of the business and the subject area. This workshop format is designed to meet both of these needs and uses two tools to find the most effective system design: EventStorming and Bounded Context Canvas.

image

“I developed this canvas in the process of conducting DDD workshops at public events and corporate sessions. Feel free to change its structure if you find formats that are best suited for you. ”

Recipe


The main recipe consists of the following:

  1. EventStorming (minimum 1 hour).
  2. Modeling candidates for a bounded context (minimum 30 minutes).
  3. Modeling the flow of domain messages (at least 30 minutes).
  4. Bounded Context Canvas (minimum 90 minutes).
  5. Creating contextual maps (at least 45 minutes).

As a starting point, I recommend allocating a whole day for this workshop. This will help you understand how much time you really need to conduct the workshop correctly. If it’s expensive (time-consuming) to gather everyone together, try to immediately allocate two days to get everything done.

Ideally, participants should be subject matter experts and technical experts. If this is difficult to organize, then try to ensure that domain experts are at the workshop for at least the first hour.

Basic principles of modeling


To conduct a session with experts, you need a spacious room. If you choose a small audience, you will most likely be disappointed with the results. Each group of 4 people will need at least 4 meters on the wall.

I will describe my methodology in a free form, without strict regulations. However, keep in mind:
“We are constantly switching between the problem space and the solution space. "We are looking for information, creating a model, looking for additional information, updating the model, etc."
And another important point: the purpose of the session is to develop options and develop the ability to offer better options in the future.

1. EventStorming


To design a system, you need two things: a good enough general idea of ​​the entire system and a fairly deep understanding of the details in each area. To do this, let's start with EventStorming .

EventStorming is a collaborative design method that allows you to simulate a large problem area from start to finish, and also allows you to drill down a large number of details where necessary.

image

If this is your first time doing this, I recommend that you set aside 1-2 hours on EventStorming. After completing EventStorming, I recommend splitting into groups of 4 people.
At TechLead Conf 2020, Sergey Baranov will talk about practical experience with EventStorming .

2. Search for candidates for bounded context


After your domain is modeled broadly and deeply on EventStorming, you can begin to group and merge fragments in a bounded context.

image

There are many methods for determining bounded context. I recommend starting with the following:

  • Start with value — identify the core parts of the domain that are most valuable to the business.
  • Start with a simple one - create a naive model by breaking the timeline into successive steps.
  • Look for key events - business events that affect different parts of the business process.

For the first time, spend no more than 30 minutes on this task. Invite the group to create the original bounded context model as a starting point. It does not have to be perfect and is unlikely to be the final solution.

The output should be in a list of bounded context names on a flipchart or paper. You cannot physically modify EventStorming if you have multiple groups.

Next steps


You may immediately see several ways to model the system. For now, choose one of them for work and write down other possible models (they will be useful later). You can also understand that you are missing domain information. If so, do another round of EventStorming.

3. Modeling domain message flow


One way to validate your design and look for improvement points is to visualize the interaction of bounded contexts in complete business system scenarios.

If the domain flow turned out to be complex, with a large number of dependencies and bi-directional connections, then your design is fragile and needs further analysis.

There are many visualization methods that can be used to model flows and use cases, including UML sequence diagrams and UML use case diagrams. I recommend using the domain storytelling option .

When modeling the message flow of a subject domain, bounded contexts are the actors in the story. Thus, a typical story begins with the user trying to achieve some goal, and the interaction between bounded contexts is aimed at providing the user with a solution.

image
A fictional example of a domain message flow

Modeling strategic domain flows allows you to get feedback on the proposed bounded contexts. It shows how contexts collaborate with each other and depend on each other to complete a complete business process. This can help find an alternative design.

The question you should ask yourself is whether the description of each bounded context matches the role that it plays in the domain stream. If not, it is likely that the name or context boundaries require redesign.

Next steps


Because your domain flows determine the relationship between bounded contexts, you can immediately spot obvious design flaws. You can go back to the previous action and update the candidates for a bounded context or perform a second iteration of EventStorming. You can also write down your thoughts on design and collect more information about the next steps before starting the redesign.

4. Bounded Contexts Canvas


The next stage of design is the development of candidates for a bounded context, using details of key design criteria. Your team should choose the bounded context that you consider most important. Limit the discussion to a maximum of 3 minutes. It is not critical to be 100% accurate.

Now draw a Bounded Context Canvas and follow these steps to fill in the details. I recommend using 1 sheet of flipchart or paper of the same size.
After completing these steps, repeat the process until you have identified all your bounded contexts. Try to divide your time equally between the identified candidates for bounded context.

4.1 Definition of the general context


Start by defining the name of your bounded context and its description. The description should show the purpose of the context in the domain and its role in the business, and not the implementation details.

Next, you need to make a strategic classification. Is bounded context the main part of the system, an auxiliary element, a common one or something else? Read the post of Vlad if you need help choosing.

image
As an example, a filled Bounded Context Canvas after going through the 1st step.

Next steps


If you cannot come up with a clear name, or write a coherent, accurate description, or your terms for Ubiquitous Language (UL) are ambiguous, consider this as feedback for your design. Consider redesigning the borders, or take a note and come back later (it is usually better to come back later).

4.2 Clarification of business rules and the formation of a common language


Now go back to EventStorming and look at the notes for this bounded context. Find the most important business rules and policies, then try to select the 3 most important and add them to the canvas.
Konstantin Gustov at TechLead Conf 2020 will talk about his many years of experience with Ubiquitous Language and other DDD components in Raiffeisen.
This is also a good time to search for key business words or phrases to add them to the canvas in the Ubiquitous Language section. You will continue to add words and phrases throughout the workshop, now this is only the starting point.

image

4.3 Feature Analysis


The next step is to explore the possibilities provided by the bounded context. This not only clarifies what he is doing, but also gives a lot of feedback for the design. You can ask questions such as:

  • Is this context overloaded with responsibilities?
  • Do opportunities look related?
  • Do the capabilities match the name and description of the context?
  • What if we move this opportunity out of context?

Start defining opportunities by introducing a public interface. What can consumers request from this bounded context and what commands can they invoke? Use domain data streams to see what consumers need from this bounded context.

Not all features are activated by commands and requests from outside. Some features may be launched from within. For example, scheduled tasks. Sometimes you may notice that opportunities are clustered, for example, a command, request, and notification. If so, put them together on the canvas and give the cluster a name.

You may get the feeling that responsibility is inappropriate and should relate to another bounded context. If so, select it with some kind of identification mark on the sticker.

image

Next steps


If you find it difficult to determine context capabilities or feel that some of them are missing, I recommend returning to EventStorming and modeling this bounded context in more detail with a focus on finding the capabilities needed for other contexts or services.

Deepening capabilities [optional]


Lay out every opportunity on your canvas for additional features. This additional detail will help you find alternative models. If there is not enough space on the canvas for parts, find another sheet of paper or space on the wall. You can go as many layers deeper as you see fit.

4.4 Dependencies


Dependencies are necessary if we want modularity, but they also cause a wide range of business, technical and social problems. Therefore, it is important to see the dependencies, to understand their influence, and to consider alternative options. And so the last step in designing a bounded context is to ensure that you capture all the key dependencies of your bounded context.

Looking through the EventStorming result and domain flow diagrams, identify each dependency that has a bounded context and write down the following information:

  • the name of another bounded context or service;
  • A brief explanation of why addiction exists
  • where is the dependency: inside this system or in an external system (for example, a third-party service);
  • relationship type: this is an incoming dependency (another service depends on this bounded context), outgoing (this bounded context depends on another), bidirectional or user interface (the dependency is some type of user interface).

Question each of the dependencies: whether it is needed, what are the costs and benefits of its availability. If it seems that you can do without it, mark the dependence with a yellow sticker.

image

4.5 Constructive criticism


When you have completed filling in the canvas, take a few minutes to critically evaluate the resulting design of your bounded context. Break your reviews into the following categories:

  • Good : design aspects that you like.
  • Bad : design aspects you don't like.
  • Unsure : design aspects you are not sure of.

4.6. Reflection and repetition


Good design is iterative. Before moving on to the next bounded context, step back and look at the big picture. Have you learned anything that is contrary to your design? If so, cross out the proposed boundaries, and then continue to design the next bounded context.

At this point, ask yourself if the domain is modeled in sufficient detail. Was it difficult to fill some parts of the canvas? If so, try another round of EventStorming throughout the domain or in some parts of it.

5. Creating context maps


After creating a canvas for each bounded contexts and collecting design feedback, the next part of the session is a return to exploration. This time you have a complete set of knowledge that will help you find the best design options.

The result of this exercise is a collection of basic context maps - visualizations of the structural relationships between bounded contexts and any other diagrams that you consider necessary, such as diagrams of domain flows. Each team must develop at least 3 context maps, each of which will show possible options for building the system.

image
An example of a very accurate context map, for this workshop it is enough.

We will hold a mitap at TechLead Conf 2020, where we will analyze the various techniques, patterns and anti-patterns of DDD and collect a visual radar. Which will be published after the conference.
Final activity can be carried out in free form. The goal is to review the information collected and use it to develop a number of system designs. As a starting point, I recommend:

  • View all reviews collected for each context and experiment with “bad” and “insecure” reviews.
  • Ask “what if” questions ...
  • “What if we transfer this opportunity to another bounded context?”
  • “What if we break this opportunity and move one of the subfunctions to another bounded context?”
  • “What if we split the bounded context into several contexts?”
  • “What if we take an opportunity from each of these three contexts and use it in a new context?”
  • “What if we duplicate functionality to remove addiction?”
  • “What if we create a common service to reduce duplication in different contexts?”
  • “What if we isolate truly key opportunities and move the rest to a more peaceful place, in a separate context?”

If you prefer visualizing these transformations, the following illustrations may be helpful:

image

image

image

Workshop closing


To complete the session, each group should present a selection of the context maps they created and discuss the trade-offs of each design. You need to explain your choice, for this usually a presentation for 5-10 minutes is usually enough.

What you need to consider in the presentation:

  • : .
  • : .
  • , , .

- TechLead Conf 8 9 . 32 , , , , DDD .

- — ( , ). , .

More articles:


All Articles