What this looks like in practice
Bounded contexts: where one language ends and another begins.
The single most valuable output of Big Picture Event Storming is the discovery of your bounded contexts: the natural seams in your business where one department's language stops making sense and another's takes over. Sales talks about Leads and Opportunities; Fulfillment talks about Shipments and Routes; Accounting talks about Invoices and Journal Entries. Same company, three vocabularies. These seams are the right place to split services, databases, and teams. Getting this right is the difference between a modernization that scales and one that recreates the monolith in a new language. We deliver a context map showing every bounded context, the upstream/downstream relationships between them, and the translation layers where terminology changes.
Aggregates, commands, and events: the CQRS skeleton.
Inside each bounded context, Design-Level Event Storming identifies the Aggregates, the units of consistency in your code. An Aggregate (say, Order) is a cluster of domain objects that must change together and is protected by invariants enforced in one place. Every command that changes state goes through an aggregate; every event the system emits comes from one. You walk away with a structured catalog: a list of every command (Submit Order, Reserve Inventory, Capture Payment), a list of every event (Order Placed, Inventory Reserved, Payment Captured), and the mapping between them. This is, quite literally, the first draft of your API. It's also, quite literally, the event schema for your event store. The same artifact drives both the write side and the read side of a CQRS architecture.
Policies, read models, and the workflow of the whole system.
Policies capture the "whenever X happens, do Y" logic that glues events to commands. In a CQRS and Event-Sourced system, policies are where Sagas live, where Process Managers orchestrate multi-step workflows, and where eventual consistency is reasoned about. We deliver them as an explicit list, so your engineers never have to guess what's supposed to happen when an event fires. Read Models capture every view the business needs: the "Order History screen," the "Revenue Report," the "Unshipped Orders Queue." In CQRS, these are projections built from the event stream. Identifying them up front means we know exactly what queries the system must support, which determines how the read side is optimized.
A handover package, not a meeting memory.
At the end of the engagement you receive: the full Miro board (archived, yours forever), a written context map, a structured JSON/Markdown catalog of every aggregate, command, event, policy, and read model, an architecture recommendation (CQRS, Event Sourcing, or a simpler pattern if complexity doesn't warrant it), and a phased implementation roadmap with risks flagged. If you want, we implement it. If you have an internal team, we hand it over and stay on for architectural review. Either way, the domain knowledge is now captured in a form your organization owns, not locked in a consultant's head, and not dependent on the one senior engineer who understands the legacy system.
What you walk away with
- A context map showing bounded contexts and the translation layers between them. Your service/team boundaries.
- A structured catalog of aggregates, commands, and events. The first draft of your API and your event schema.
- Explicit policy and saga definitions. The glue for multi-step workflows in a CQRS/Event-Sourced system.
- A read-model inventory. Every projection the business needs, sized and prioritized.
- An architecture recommendation matched to your actual complexity. Not CQRS-by-default.
- A phased implementation roadmap with the riskiest items surfaced and mitigated first.