Drafting an architecture vision is one of the most valuable outcomes of a DDD (Domain Driven Design) Big Picture Event Storming. Having an architecture vision is key to sustainable, successful and evolutionary design. Have a look at the first posts for full explanations.
This is the 9th post in a series about how to use Event Storming to kick start architecture on good tracks. It might be a good idea to start reading from the beginning.
We can use this technique to draft a target architecture on top of a DDD Big Picture Event Storming. That is for 2 reasons:
- It won’t work without the shared knowledge built with Event Storming
- We’ll re-use the design board
A good way to run this architecture draft workshop is to continue on the next day! Check the previous chapters to know how to do this.
Here is how to do it in more details.
The first step to draft a functional architecture vision is to draw the Bounded Context. If you prefer, you can use the term “Functional Area” instead, which are a jargon-free synonym to Bounded Context.
💡 Bounded Contexts are the most important part of Domain Driven Design. Maintaining a strong decoupling between different bounded contexts makes large systems more simple.
At the end of the DDD Big Picture Event Storming, the design board should look something like that:
As you can see, Domain Events and other post-its gather together in groups. These groups are “proto bounded contexts”.
To materialize these further, try the following:
- Ask for a volunteer
- some colored, thick, wool string
- adhesive tape
- With your volunteer, walk the board from left to right, identifying bounded contexts.
- Discuss a bit. You will usually agree about bounded context boundaries
- Ask the audience for a bounded context name. Tip: Look into names in “ing” for good ones (ex: accounting, ordering)
- It might also be the occasion to capture a few domain definitions. Be sure to keep your definition post-its at hand
💡 Wool, scissors and adhesive tape is all you need to draw bounded contexts on an DDD Event Storming design board.
At this point, the outcomes are all about improved communication and collaboration.
Here is one key aspect of bounded contexts. The same concept might represent different thing in different contexts! (That’s why they are called Bounded Contexts.) Let’s think of the order entity in an e-commerce system for example. Orders have different responsibilities if we are talking about shopping, billing or delivering. Bounded contexts are an opportunity to specialize your domain definitions to different contexts. It’s a way to grow your ubiquitous language.
To be continued
This was only the first step in drafting a functional architecture vision. In the next post, I’ll go over how to identify core contexts. The 20% of your codebase that should get 80% of your efforts!
This was the 9th post in a series about how to use Event Storming to kick start architecture on good tracks.