Bounded Context is a way of dividing the system into separate business and technical areas. This concept was brilliantly visualized by Nick Tune in his Bounded Context Canvas:
However, the question arises how to show the processes inside this kind of a Bounded Context.
Where does the need come from?
Let’s assume we have a business process like this:
- We have a BC Payments, which carries out the order payment process
- BC receives the event Order placed, and responds Payment successful or Payment declined
- Inside BC we want to be able to choose the payment method, process payments through the gateway, handle errors, repeat payments, etc.
For a long time, I felt that there was step missing between Event Storming Process and Design Level:
- Process Level - we go through the entire process, describing the operation of the entire system - then we do not want to deal with the details of a given module.
- Design Level - we enter the level of aggregates and data modeling - then it is easy to focus on aggregates / entities / VO and not on the process inside BC.
If we want to show work inside and outside of BC, we must do something in between. I thought about giving this approach a different name - to make it a definition I can use to talk to my clients and colleagues more easily.
Hence the general term Event Storming - Bounded Context Level.
Where to start
We use this approach when:
- You have performed Event Storming Process Level and have a general understanding of how our system works.
- You have pre-planned the shape of your BC - e.g. based on the Bounded Context Canvas.
Our ES PL and BCC for the payment process could for example look like this:
Of course, after a more thorough analysis of the process, these limits may change. However, this is a good starting point for writing down internal, lower-level processes.
Event Storming - Bounded Context Level
Check out this example of what the Payments module would look like during such a workshop:
You can clearly see:
- Opening the payment
- Selecting a payment method
- Communication with external systems
- Payment declined
- Counter for the maximum amount of time for payment
It looks like the Event Storming Process Level, with 4 differences:
1. Division of outer and inner components
In the diagram, we have a clearly defined boundary of what BC of payments is. Everything that is inside this BC is invisible outside - events, policies, actions. Only the elements lying on the BC shore are covered by the communication contract.
2. External event handling
When an external event comes to us, we must use a policy to properly handle it. At this point, we open an internal process that will guide the customer through the payment process. Thanks to this, we create a distinction between what an external contract is and what impact it has on us internally.
2. Mapping the initial positive event
When we complete the internal payment process, we want to notify the internal world about it. You can output our base event, but this is not always a good option. Sometimes:
- the event is too detailed
- the event does not have all the required data
- the event may be incomprehensible from outside the module
Then it is a good idea to replace the internal event with an external event. It has a different shape - it has data tailored to our listener, and not to the needs of our internal process.
3. Mapping the output negative event
We proceed similarly in negative events intended to immediately end the process. We may have several different places where our process ends. Then having one negative translator facilitates and flattens external communication. For our client, it may be unnecessary to distinguish the reason for the rejection of the payment into 2 different events.
Summary
At the Bounded Context level, Event Storming technique allows to precisely plan the work of a given module. You can concentrate your work on one area, leaving everything else aside. At the same time, there’s no need to reach the level of technical aggregates. This allows you to keep the discussion at the business level and include people such as Product Managers, testers, and analysts in the discussion.
I accept that some of you treat what I described above as an element of ES PL. Others may consider it an element of ES DL. Well, I don’t think I’ll convince everyone 😀
