Using Event Storming and DDD to prototype (micro)services and NFRs - 1

DDD Big Picture Event Storming is a great support to draft (micro)services boundaries and NFR prototypes. Let’s see how to with this workshop activity.

Previous posts presented how to use Event Storming to draft a functional architecture. In the previous post, I suggested to realize this target vision incrementally. This means starting with something simpler.

Let’s illustrate this. It’s not because the vision has open host services APIs that we should create services right from day-1. This brings up a new challenge though. How to make sure we don’t fall in a performance NFR (Non Functional Requirement) dead-end down the road? This kind of late discovery is very difficult to deal with. They often lead to crunch hours and non-sustainable pace.

💡 Late discoveries of NFR problems leads to crunch hours and non-sustainable pace.

In this post, I’ll present how we can check our Event Storming design against expected NFRs. 

This is the 15th post in a series about how to use Event Storming to kick start architecture on good tracks. To get the most out of this post, it’s a good idea to start reading from the beginning.

An activity to check performance NFRs

This activity can happen right after the Event Storming, with the full audience. But you can also do it the day after, with a smaller group of volunteers.

Ask the audience for 3 performance critical use cases. For every use case, do the following:

• 1. Ask someone to explain the use case
• 1. Ask the audience to estimate the expected user performance requirements
• 1. Walk the use case through the events on the board.

• 1. The use case will go through some open host service APIs of the draft architecture. Discuss and estimate how the end user performance will translate through each. For example, you’d want to have an idea of the number, size and frequencies of messages.
• 1. Discuss whether its going to be ok or not:
     • If you reach a consensus that it’s going to be ok, then it seems you are safe enough with this design 
     • If you quickly conclude that it’s not going to be ok, you’ll have to rethink your design and try to find something else
     • Finally, there is the situation where you cannot reach a consensus or where the consensus is that you don’t know. It’s a good time to schedule a prototype.

Build prototypes to get your answers

Prototypes are about getting answers to specific questions with the minimal efforts. From the previous activity, we should have a clear question in mind. Let’s suppose the question is: “Can we handle N messages, of size S, at frequency F?”. We don’t need the full system to test this, just design a fake experiment, with fake messages. We don’t need to test every message passing framework out there to find the best one either. As long as we find one that fits the bill, we’re safe. We can defer the real choice.

The exact details of the prototype itself do not have to specified during the workshop. The only thing that needs to come out of the workshop is the question we need to answer. Let’s use a pink (problem) post-it for that. (Cf post about agenda of Event Storming for description of pink problem post-its.)

Materialize processes and services

We already had a lot of thoughts about relationships, APIs, messaging and NFRs. It’s only a small step further to draft processes and services boundaries.

Here is a 2 steps activity to do this:

1. Present service principles

Here is a short list that you might want to adapt according to your context

We can notice that bounded contexts typically fulfill the inside principles by design. That’s why they make pretty good service candidates.

To learn more about services principles, check this talk about evolutionary architecture. (By Ionut Balosin and my friend Xavier René-Corail)

2. Materialize your processes

To materialize your services or processes on the board, use wool, as you did for bounded contexts. (cf post Identify Bounded Contexts ) It’s better to use wool of a different color.

💡 Use wool, scissors and scotch tape to materialize services on your Event Storming board.

3. Optionally, draw an architecture schema

When done, you can draw your service architecture on a sheet of paper. It’s better to stick to back-of-a-napkin style diagrams. It’s only a draft, and you’ll need to update it throughout the life of the project. Even so, once we’ve striped out all the post-its, the diagram gets pretty simple. It becomes a lot easier to share and view on a screen. (I should write a post about how to curate knowledge out of an Event Storming workshop)

To Be Continued

I’m not done yet with this activity. This post was a walkthrough of this Event Storming follow-up activity. The next post will detail outcomes and tips about how to make this activity successful.

Continue Reading…

This was the 15th post in a series about how to use Event Storming to kick start architecture on good tracks. The next post will be about a follow-up workshop to get insights whether to rewrite or refactor.

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"!