Discovering Bounded Contexts
Domains belong to the problem space. They define different aspects of running a business. Domains aren’t tied to any specific technology, architecture or methodology. They tell you nothing regarding how to actually implement them, or even how to define boundaries and communications. Therefore, after discovering domains it’s time to start thinking about solutions. Enter Bounded Context.
Bounded context vs domain
Difference between domain and bounded context is often elusive. Even DDD practitioners often use these words interchangeably. How many times you’ve named class definition an object? That’s similar. So, what are the key differences? First of all, bounded contexts define meaning of words and types of relationships between teams. For example, we can say that sales bounded context is a customer of product catalog bounded context. This clearly defines team boundaries. Most probably, the product catalog team will expose some API that will be consumed by sales team. Sales team might have a completely different meaning for concepts such as “product” than product catalog team. Bounded contexts are usually organized around teams, organizations or features. In this example, there’s one domain (e.g. the ecommerce) with two different bounded contexts: “sales” and “product catalog”. Note, that domain doesn’t necessarily require you to carve these contexts. You could still design your system, so these teams are working as one and they don’t need to be separated yet. In such a case, they might create one simple monolithic context. And it might be just enough for our needs at this stage.
So, bounded contexts are boundaries of meanings. Inside the same context, we all must speak the same language. Business talks, sending mails, writing documentation, code — all of these should use exactly the same meanings. In code, bounded contexts often are implemented as (one or more per context) modules. In an ideal scenario, there should be one module per one context and module should be relatively small. This usually means our contexts are of right size. Relationships between these contexts are often drawn using Context Map.
You can design individual contexts using tools such as Bounded Context Canvas.
Before we can get into finding bounded contexts, we first need to start crunching the domain knowledge.
Knowledge crunching
Knowledge crunching is the process of knowledge extraction. It’s called “crunching”, because we try to chop smaller parts of the knowledge into manageable pieces. We extract domains, subdomains and generic domains. This will eventually lead us to discover the bounded contexts.
There are many ways you can learn more about your domain. People used to do that before the advent of DDD or any other supporting tools. We might, for example, simply talk on a regular-basis with the domain experts and note everything. However, usually some more collaborative approach is a better choice, such as Event Storming.
Event storming
Event storming is a workshop-style approach to explore the domain and find critical business processes.
There are multiple storming formats with different goals in mind. However, the most popular is Big Picture.
Big picture
The goal of the big picture format is to explore the domain. At the end of the big picture all participants should have quite good overview of the business in its entirety.
To succeed, we need to gather all the people who care about the business. Domain experts, business analysts, project managers, developers and even C-level executives. Basically, everyone who wants and can contribute during the workshop. In the days before remote work became a standard we used to gather all the people in the same, almost completely empty, room. Then, the facilitator (the show runner) would ask all the participants to start placing sticky notes expressing important facts (events) on a huge wall. According to Alberto Brandolini, the author of event storming, it’s the preferred way of running storming sessions. Reading the body language by the facilitator, for example, can bring very essential details about problems or opportunities. Nowadays, we usually use collaborative online tools, such as Miro.
No matter whether we run storming sessions in the same room or use some digital tool from our homes, the big picture stage is always very chaotic. That’s how the wall might look like after a while.
Now, in order to start discovering bounded contexts we need to make a cohesive narration. It’s just like trying to order some facts according to timeline to tell the story of Cinderella starting with some random order of sentences.
Now, we could start just by taking any random fact and trying to place in the right order. However, this will be very ineffective, especially when there are a lot of facts to be ordered. Instead, we can try to find the most important events (like 3 or 4 events) in the entire story. By “most important” we mean events that separate story phases.
The selection is arbitrary and can change later on. But we need to start with something, right? So, this time we decided to choose the following key events “the prince fell in love with Cinderella”, “the daughter is left with her stepmother and her daughters”, “the fairy appeared” and “Prince found the Cinderella’s shoe”. Now, let’s sort just these key events.
Now, all we have to do is to place each event between the key events. We simply take any event from the chaos space and ask ourselves: should it happen before or after the given key event?
Finally, we found the right spot for the “everyone is invited to join the prince’s party” event.
Now, we repeat exactly the same thing for every event left.
That’s how the final result might look like.
We have quite a nice story out there. And you know, what’s really awesome? You can apply the same pattern to find the meaning in your business!
Now, while finding the meaning in fairy tales is quite the same thing as ordering events gathered during big picture event storming format, it’s not exactly the best way to explain how to find contexts and processes. After all, there are not many business teams in fairy tales ;).
Therefore, let’s switch the context now and let’s take a look at the crowdfunding investment domain. For the needs of this article, let’s consider the CrowdSorcery project.
CrowdSorcery
CrowdSorcery allows Investors to invest into any kind of Asset. Borrowers then repay Loans. CrowdSorcery is a fundraising platform which allows investors to allocate their money passively into groups of assets using automated strategies.
On the other hand, borrowers can easily finance their Projects with elastic interest rate.
That’s how the ordered events might look like after the big picture session.
Heuristics used to discover bounded contexts
Now, it’s finally time to find the bounded contexts.
You can’t automate good design. It’s an art and engineering in equal parts. Therefore, it’s completely natural for contexts to keep evolving. More often than not contexts will be separated or merged. This is the law of every living organism.
So, you might wonder: is there any approach we can use to discover the right boundaries? Alberto Brandolini suggests employing several heuristics that might help you in this seemingly daunting task.
Pivotal events
Pivotal events are good candidates for discovering contexts. Usually, what happens before is part of a different context than what happens after.
For example, events: “investment strategy chosen”, “invested into group of assets” and “funds received” are likely to be part of different context than “interest paid” and “interest not paid on time”. Note, that pivotal events might have different meaning depending on the context. If people can’t agree on the precise meaning of e.g. “project funded”, then it usually means they are talking about different contexts.
This is one of the most important heuristics in my opinion and should be almost always considered.
In this example “project funded” event is produced by project fundraising context, but might be also consumed by interest payment context. Most probably, project fundraising context won’t publish this event directly, but rather translate it into some kind of integration event being part of a published language used by both contexts.
Swimlanes
In practice, processes are never sequential. There are usually multiple branches happening at the same time. Sometime, these processes might mean completely different models. That’s not a hard rule, just an insight you might follow. If it seems processes are about completely unrelated things happening at different timelines, it’s worth to give it a try.
Here’s how it might look like according to Alberto Brandolini. Image taken from Introducing EventStorming book.
Roles
Different roles might require different needs. It’s possible that we need a very special model e.g. to handle project fundraising started by VIP clients. However, don’t be fooled. Usually that’s just the if statement in the same context. Treat this heuristic with a grain of salt and create new context only when you feel the flow is really different for given roles.
Image taken from Introducing EventStorming book
People reactions
How people react to some events or stories can bring a lot of value to find the right boundaries. People tend to group in camps based on their expertise. So, whenever you see there are groups being formed that can’t agree on the meaning of some events or sequence of steps, it’s quite a good indicator they’re talking about different contexts. Both verbal and body language communication should be considered.
Unfortunately, while being a very valuable heuristic, it’s somewhat limited during remote storming. Body language is almost completely gone. That’s why you should always require all participants to have their cameras turned-on. It’s nothing next to reading the body language in a real room, but it’s better than nothing.
Language
Finally, listen what participants say. If you hear sentences such as:
- A borrower can start the fundraising
- A borrower pays interest according to the schedule
- A borrower can create her profile
- A borrower can publish her public portfolio
It usually means different contexts. Don’t get fooled by using the same borrower word. Stick to the behavior instead of nouns.
Discovering processes
It’s time to find the key processes. After ordering the events on the timeline it shouldn’t be so hard. We just need to start asking “what caused these events”, “who|what initiated this cause” and “why”.
Now, let’s try to discover the project fundraising process by asking a series of simple questions.
- First, we ask what caused “project funded” event
- The answer is that it’s the direct cause of “funds received” event being repeated enough times
- Then, we ask again: what’s the cause of “funds received”?
- The answer: that’s the result of invoking a “transfer funds” command on some system.
- Who initiated this command?
- That’s some policy
- Why?
- Because investment into an asset has been made
And so on, until we answer all the questions.
Summary
It might seem initially, that discovering bounded contexts is some kind of magic. However, when we use knowledge crunching tools such as Event Storming, sorting business stories and applying heuristics we can eventually get really close into finding the right boundaries. At the same time we need to be aware though, that these boundaries are always evolving, especially during early stages of domain discovery.
