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 functional areas. Functional area is a jargon-free synonym to Bounded Context.
💡 Bounded Contexts are the most important part of Domain Driven Design. Maintaining a strong decoupling between different functional areas 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-functional-areas” (or proto-bounded-contexts if you prefer).
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 functional areas.
- Discuss a bit. You will usually agree about functional area boundaries
- Ask the audience for a functional area 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 functional areas 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 functional areas. The same concept might represent different thing in different areas! (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. Functional areas are an opportunity to specialize your domain definitions to different areas. 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 areas. 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.