Drafting a Functional Architecture Vision with Event Storming and DDD

We did the 1st phase of DDD Big Picture Event Storming. It’s time to build on the shared knowledge to draft a functional architecture vision. All in just a few days.

ℹ️ NOTE: An updated version of this post has been published on the Event Storming Journal blog

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.

Context

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.

Bounded Contexts

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.

A sample map of Bounded Context (aka Context Map) from martinfowler.com

💡 Bounded Contexts are the most important part of Domain Driven Design. Maintaining a strong decoupling between different bounded contexts makes large systems more simple.

Walkthrough

At the end of the DDD Big Picture Event Storming, the design board should look something like that:

A DDD Big Picture Event Storming design board, with clumps of Domain Events

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
• Grab:
  • some colored, thick, wool string
  • scissors
  • 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.

Outcomes

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.

Continue Reading.

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!