3.4 Tactical event storming

Before proceeding, check your definition of ready:

Before starting

Tactical event storming extends the strategic event maps from 2.3 Strategic event storming down into the technical design. Where strategic event storming models what is happening (the business process), tactical modeling adds how it happens: commands that trigger events, queries that fetch data, aggregates that hold business logic. The technology team drives the conversation but stays anchored to customer value so we don’t lose the original value stream in translation.

This activity is the Software Design level of event storming in Alberto Brandolini’s three-level framing (Big Picture, Process Modeling, Software Design). The two strategic levels were covered in 2.3 Strategic event storming. We retain the strategic event-map vocabulary — events, commands, state, hotspots — and extend it with the software-design artifacts below (queries, aggregates, interaction arrows, architectural annotations). The stickies on the wall stay largely where they were; we’re adding detail, not rebuilding.

You’ll be adding detail on top of existing strategic event maps. Having your context maps and user journeys readily available will help. Most important, you’ll need a clear and bounded understanding of what you’re delivering in the upcoming sprint — your product increment. If the team needs a workshop-facilitation refresher, the event storming workshop guide covers the mechanics; tactical sessions use the same format with a narrower audience.

Guide to tactical event storming

This activity will add fidelity to your strategic event maps. Refresh on event storming in chapter 2.3 if the team needs it.

Strategic event storming emphasized having the whole team present, including the customer. Tactical storming leans more heavily on the technical team members, and parts of these workshops may not require your product owner or customer. You will need your customer, subject matter experts, and product owner for a lot of the conversation, so make sure they can join as needed. As technical details are fleshed out, there will be questions only your customer can answer.

Typical format: block about half a day — a two-hour session before the lunch break followed by another two-hour session. This leaves the team plenty of time to break out with sidebars, dividing and conquering smaller pieces of work.

Commands, queries and aggregates

Our strategic event maps model business process chiefly by showing what events happen. Events are statements about something that happened; to move into technical design we need to describe how they happen. Three new artifacts layer on top of events:

1. Commands precede all events. Events like “user logged in” are statements of fact; a command is what makes the event happen. Commands are entry points to your application — they operate using an API and ultimately interface with an aggregate.
2. Queries represent information gathering. When we need to know something, we have to get that information from somewhere. Queries describe where.
3. Aggregates are the workers — the entities and objects that execute business logic. The term refers to the top-level, externally facing entity within a context. A “customer” context might have addresses and social security numbers inside, but the interface goes through the “customer” top-level object.

After an aggregate receives a command and does some work, it might emit an event. So in order to figure out how events show up on the map, we need to figure out the commands and aggregates that produced them.

Strava example. Suppose our app lets someone create a “challenge” (adding it to a list of available challenges) and later “host” it (making it a live challenge event). Hosting requires a subscription. The flow kicks off when someone submits a web form; the form creates a command (“Create Challenge”) routed to the challengeManager aggregate. During processing a query is made against a database (to update the leaderboard), and a “Challenge Created” event is emitted. Later, a “Host Challenge” command goes to the same aggregate and either a “Challenge Hosted” or “Payment Required” event is emitted.

A larger diagram shows the whole Strava hypothetical in context, with more business features supported and corresponding commands, queries and aggregates noted:

Adding architectural components

You may notice annotations indicating architectural components — for example, a “Challenge Leaderboard” query source annotated with “PSQL” (Postgres). Making these annotations now is optional — there will be future opportunities. But if it’s helpful, go ahead. Keep in mind that technology choices should align with your service catalog.

Events, APIs and interactions

Strategic event maps generally have a simple left-to-right flow. Tactical maps get more complex. Add arrows for interactions, and distinguish between events and API calls: events are strictly asynchronous on a queue, while API calls might be sync or async. Use dotted and solid lines or any other legend your team agrees on. Annotate message lines appropriately — indicate which calls are async versus sync, specify protocols, identify consumers of events.

Returning to our core use case of Sally buying a Peloton, here’s the event map from 2.3 Strategic event storming updated with commands, aggregates and queries:

The team can extend and modify the drawing style. I wouldn’t recommend deviating drastically from typical event modeling style (it could get confusing), but tuning and adding is fine. The important thing is a common drawing style that everyone understands.

Inputs

1. Availability from your entire team (the business, technical roles, and very importantly, your customer) to support the workshop.
2. A sprint backlog fully populated with your highest value feature and a clear understanding of your product increment.
3. Up-to-date business capabilities and functions, correctly describing each user journey, as well as corresponding context maps.
4. An up-to-date service catalog identifying available technologies.

Process

This is a group activity and in general, the more of the team present, the better. Some discussions may swing deeply into technical realms — use judgement about who needs to be present, but make sure the team can readily access those who can answer important questions.

Prepare

Make sure everyone is well prepared and has a clear understanding of the workshop. Refresh everyone’s memory about event mapping in general and highlight the specific objectives.

If the team needs a refresher on domain driven design, take a look at this 30-minute guide to Domain Driven Design.

Set a clear agenda. I like to share specific event maps with the working group ahead of time, establishing clear scope for the workshop. Set a time box so everyone is prepared to dedicate appropriate time and attention.

Execute

1. Review events, bounded contexts, and user journeys. The whole team revisits your strategic event maps and agrees on the existing flow.
2. Add technical fidelity. Make a copy of your event map in preparation for annotating. Keep a complete historical copy — the team needs to be free to move elements around and will need an original to consult when things get confusing. As a team, add to the drawing:
   1. Commands and queries. Commands are most often user-initiated actions to describe why an event happened — but they can be initiated by other components or external actors as well. Queries indicate where information is stored and where it comes from.
   2. Aggregates. Aggregates (your clusters of one or more entities and value objects) are identified and added. Commands are sent to an aggregate, which in turn may emit an event (but doesn’t have to). Events themselves can also be received by aggregates — for example, an aggregate might receive a “loan account created” event and translate it into a “run credit check” command.
   3. Interactions. Participants determine the interactions between events, bounded contexts, and aggregates, noting them appropriately as the interchange of messages.
   4. Architectural components. Optionally and where valuable, annotate what service, product, or supporting technology is used. You don’t need to do this now — there will be ample time in the next activity — but don’t prevent the team from adding detail here. Any technology must be present in your service catalog.
3. Iterate. Take time to reach agreement on how the system will work. This is the foundation for your technical models — any confusion here cascades into rework.

Outputs

• Tactical event maps. A new set of tactical event maps engineering and architecture teams can use to continue design and start development.
• Bounded contexts and aggregates. An updated model reflecting bounded contexts and aggregates that aligns with your strategic business goals and near-term tactical goals. Contexts should be concise and well encapsulated, aiding the rapid delivery of software.
• Inventory of commands, queries, and events. These correspond with your APIs, data sources, and interprocess messages. Clear definition supports clean boundaries and efficient, isolated, robust software.

At this stage you should have a clean, top-level design showing how your business application will function. Major components will be defined (aggregates and query sources), compartmentalizing functionality into reasonable units. Commands, queries and message lines will define clean API boundaries, making dependencies clear.

In the next chapter, you’ll go deeper into technical design with modeling exercises. Specific components will be designed at a functional level — specifying inputs, operations, and outputs. You’ll also make sure each function’s output aligns with its acceptance criteria, further protecting your core business value.

Next activity

• 3.5 Modeling