Advanced
Event-Driven Architecture
DDDEvent stormingArchitecture
Event Storming — Vocabulary
5 exercises — Learn the vocabulary of event storming workshops: domain events, commands, aggregates, policies, and hotspots.
0 / 22 completed
1 / 22
In event storming, domain events are always named:
Domain events represent something that has already happened — they are facts about the past. Past tense naming ('OrderPlaced', 'UserRegistered') makes this explicit and distinguishes them from commands.
2 / 22
In event storming notation, a command represents:
Commands are intentions or requests: 'PlaceOrder', 'CancelSubscription'. They are issued by actors or policies and, when processed by an aggregate, cause domain events to be emitted.
3 / 22
Which definition best describes a policy in event storming?
Policies (often represented as purple stickies) capture reactive business rules: 'whenever PaymentFailed, send a NotifyCustomer command'. They encode the 'if event → then command' logic of the business.
4 / 22
A hotspot during an event storming session is:
Hotspots (red stickies) are placed where participants disagree, where the domain is poorly understood, or where technical/business complexity is high. They become the agenda for follow-up deep-dive sessions.
5 / 22
What is the role of a read model in an event storming diagram?
Read models (query-side projections) represent the information visible to an actor when deciding whether to issue a command — e.g., 'the order summary screen' that a user sees before clicking 'Cancel Order'.
6 / 22
Reviewer: 'Okay, I've reviewed the PR. The `OrderCreated` event seems a little… verbose. It's carrying a lot of data that isn't strictly *required* for downstream systems to react to. Shouldn't we consider splitting it into smaller events – perhaps an `OrderPlaced` and a separate `PaymentReceived`? This aligns with our Event-Driven Architecture principles, right?'The question presents a realistic code review scenario where the reviewer is advocating for event decomposition. It's crucial to understand that splitting an event into smaller, more focused events (like `OrderPlaced` and `PaymentReceived`) aligns with Event-Driven Architecture's core principles of minimizing coupling and promoting bounded contexts. Option A incorrectly frames it as just a personal opinion; option B oversimplifies the benefits, and option D accurately captures the reviewer's insightful suggestion, demonstrating an understanding of domain events and microservices best practices.
7 / 22
Reviewer: 'The team's been discussing the `UserRegistered` event. I'm noticing we haven't explicitly defined a *saga* for it in this diagram. While we've identified potential downstream systems like the CRM and marketing automation, the flow of compensating actions or error handling isn't clear. Shouldn't we be considering how to handle eventual consistency issues and potential failures within this event's journey?'This question tests your understanding of how Event Storming relates to broader architectural concerns. While Event Storming focuses on identifying events and their relationships, it doesn't automatically dictate the implementation details like sagas or error handling. The reviewer is highlighting a critical gap: the need to explicitly define how the system will recover from failures within the event's lifecycle – that's precisely what a saga provides. Recognizing this connection bridges the gap between the diagram and actual system design.
8 / 22
During a code review, Lead Developer Sarah says: 'I'm seeing that the `ProductAddedToCart` event is generating a lot of noise. It's bouncing between multiple services just to validate inventory and update user preferences. We should consider introducing a *domain event aggregator* – a central point where these events converge before being distributed. This would simplify our architecture and improve performance.' What does Sarah primarily suggest?
Sarah's suggestion of a domain event aggregator addresses the identified issue of excessive event bouncing. This concept—a central point for event convergence—directly tackles the problem of redundancy by consolidating events before distribution to downstream systems. A key benefit is reducing coupling and simplifying architectural complexity; it's not about scaling services directly, but about optimizing event flow.
9 / 22
Reviewer: 'Okay, I've reviewed the PR. The `OrderCreated` event seems a little… verbose. It's carrying a lot of data that isn't strictly *required* for downstream systems to react to. Shouldn't we consider splitting it into smaller events – perhaps an `OrderPlaced` and a separate `PaymentReceived`? This aligns with our Event-Driven Architecture principles, right?'The question presents a realistic code review scenario where the reviewer is advocating for event decomposition. It's crucial to understand that splitting an event into smaller, more focused events (like `OrderPlaced` and `PaymentReceived`) aligns with Event-Driven Architecture's core principles of minimizing coupling and promoting bounded contexts. Option A incorrectly frames it as just a personal opinion; option B oversimplifies the benefits, and option D accurately captures the reviewer's insightful suggestion, demonstrating an understanding of domain events and microservices best practices.
10 / 22
Reviewer: 'The team's been discussing the `UserRegistered` event. I'm noticing we haven't explicitly defined a *saga* for it in this diagram. While we've identified potential downstream systems like the CRM and marketing automation, the flow of compensating actions or error handling isn't clear. Shouldn't we be considering how to handle eventual consistency issues and potential failures within this event's journey?'This question tests your understanding of how Event Storming relates to broader architectural concerns. While Event Storming focuses on identifying events and their relationships, it doesn't automatically dictate the implementation details like sagas or error handling. The reviewer is highlighting a critical gap: the need to explicitly define how the system will recover from failures within the event's lifecycle – that's precisely what a saga provides. Recognizing this connection bridges the gap between the diagram and actual system design.
11 / 22
During a code review, Lead Developer Sarah says: 'I'm seeing that the `ProductAddedToCart` event is generating a lot of noise. It's bouncing between multiple services just to validate inventory and update user preferences. We should consider introducing a *domain event aggregator* – a central point where these events converge before being distributed. This would simplify our architecture and improve performance.' What does Sarah primarily suggest?
Sarah's suggestion of a domain event aggregator addresses the identified issue of excessive event bouncing. This concept—a central point for event convergence—directly tackles the problem of redundancy by consolidating events before distribution to downstream systems. A key benefit is reducing coupling and simplifying architectural complexity; it's not about scaling services directly, but about optimizing event flow.
12 / 22
Reviewer: 'Okay, I've reviewed the PR. The `OrderCreated` event seems a little… verbose. It's carrying a lot of data that isn't strictly *required* for downstream systems to react to. Shouldn't we consider splitting it into smaller events – perhaps an `OrderPlaced` and a separate `PaymentReceived`? This aligns with our Event-Driven Architecture principles, right?'The question presents a realistic code review scenario where the reviewer is advocating for event decomposition. It's crucial to understand that splitting an event into smaller, more focused events (like `OrderPlaced` and `PaymentReceived`) aligns with Event-Driven Architecture's core principles of minimizing coupling and promoting bounded contexts. Option A incorrectly frames it as just a personal opinion; option B oversimplifies the benefits, and option D accurately captures the reviewer's insightful suggestion, demonstrating an understanding of domain events and microservices best practices.
13 / 22
Reviewer: 'The team's been discussing the `UserRegistered` event. I'm noticing we haven't explicitly defined a *saga* for it in this diagram. While we've identified potential downstream systems like the CRM and marketing automation, the flow of compensating actions or error handling isn't clear. Shouldn't we be considering how to handle eventual consistency issues and potential failures within this event's journey?'This question tests your understanding of how Event Storming relates to broader architectural concerns. While Event Storming focuses on identifying events and their relationships, it doesn't automatically dictate the implementation details like sagas or error handling. The reviewer is highlighting a critical gap: the need to explicitly define how the system will recover from failures within the event's lifecycle – that's precisely what a saga provides. Recognizing this connection bridges the gap between the diagram and actual system design.
14 / 22
During a code review, Lead Developer Sarah says: 'I'm seeing that the `ProductAddedToCart` event is generating a lot of noise. It's bouncing between multiple services just to validate inventory and update user preferences. We should consider introducing a *domain event aggregator* – a central point where these events converge before being distributed. This would simplify our architecture and improve performance.' What does Sarah primarily suggest?
Sarah's suggestion of a domain event aggregator addresses the identified issue of excessive event bouncing. This concept—a central point for event convergence—directly tackles the problem of redundancy by consolidating events before distribution to downstream systems. A key benefit is reducing coupling and simplifying architectural complexity; it's not about scaling services directly, but about optimizing event flow.
15 / 22
Reviewer: 'Okay, I've reviewed the PR. The `OrderCreated` event seems a little… verbose. It's carrying a lot of data that isn't strictly *required* for downstream systems to react to. Shouldn't we consider splitting it into smaller events – perhaps an `OrderPlaced` and a separate `PaymentReceived`? This aligns with our Event-Driven Architecture principles, right?'The question presents a realistic code review scenario where the reviewer is advocating for event decomposition. It's crucial to understand that splitting an event into smaller, more focused events (like `OrderPlaced` and `PaymentReceived`) aligns with Event-Driven Architecture's core principles of minimizing coupling and promoting bounded contexts. Option A incorrectly frames it as just a personal opinion; option B oversimplifies the benefits, and option D accurately captures the reviewer's insightful suggestion, demonstrating an understanding of domain events and microservices best practices.
16 / 22
Reviewer: 'The team's been discussing the `UserRegistered` event. I'm noticing we haven't explicitly defined a *saga* for it in this diagram. While we've identified potential downstream systems like the CRM and marketing automation, the flow of compensating actions or error handling isn't clear. Shouldn't we be considering how to handle eventual consistency issues and potential failures within this event's journey?'This question tests your understanding of how Event Storming relates to broader architectural concerns. While Event Storming focuses on identifying events and their relationships, it doesn't automatically dictate the implementation details like sagas or error handling. The reviewer is highlighting a critical gap: the need to explicitly define how the system will recover from failures within the event's lifecycle – that's precisely what a saga provides. Recognizing this connection bridges the gap between the diagram and actual system design.
17 / 22
During a code review, Lead Developer Sarah says: 'I'm seeing that the `ProductAddedToCart` event is generating a lot of noise. It's bouncing between multiple services just to validate inventory and update user preferences. We should consider introducing a *domain event aggregator* – a central point where these events converge before being distributed. This would simplify our architecture and improve performance.' What does Sarah primarily suggest?
Sarah's suggestion of a domain event aggregator addresses the identified issue of excessive event bouncing. This concept—a central point for event convergence—directly tackles the problem of redundancy by consolidating events before distribution to downstream systems. A key benefit is reducing coupling and simplifying architectural complexity; it's not about scaling services directly, but about optimizing event flow.
18 / 22
During a standup meeting, Developer Alex says: 'We're using event storming to map out the flow of events for our new payment processing system. Specifically, we're focusing on identifying the key hotspots – those moments where decisions are made and significant changes occur.' Which of the following best captures Alex's explanation?
Alex correctly describes a *hotspot* in event storming as a critical point within a process flow. This highlights areas where decisions are made or significant changes occur – often representing potential bottlenecks or areas needing focused attention. Misconceptions might include thinking hotspots solely relate to code or architectural diagrams, or that event storming is only about visual documentation.
19 / 22
In a Slack message from DevOps Engineer Ben, he writes: 'I'm seeing the `OrderConfirmed` event generate an excessive number of notifications. The current implementation triggers alerts for every confirmation, regardless of order volume. We need to refine the event schema to only send alerts based on specific thresholds.' What does 'event schema' most likely refer to in this context?
'Event schema' in this context refers to the formal specification detailing the data structure, format, and semantics of an individual event. Ben is concerned about a poorly designed event that's triggering unnecessary alerts. This highlights the importance of well-defined schemas for effective event processing and alerting – preventing noise and ensuring relevant notifications.
20 / 22
Lead Developer Maria is reviewing a PR containing an `ItemPurchased` event. The PR description states: 'This event captures the moment a user adds an item to their cart. It includes details like item ID, quantity, and price.' Maria asks the developer: 'Are we considering using a delta event for this scenario?' What is Maria suggesting?
Maria is suggesting the use of a *delta event*, which represents incremental updates to the cart state. Rather than generating a new `ItemPurchased` event for every purchase (a full event), a delta event would capture only the changes – like quantity increases or decreases. This reduces message volume and improves system performance by minimizing unnecessary event creation.
21 / 22
During a code review, Senior Developer David says: 'I noticed the `UserLoggedIn` event isn't explicitly handling potential failures. If authentication fails, we should emit a dedicated *error event* to signal that something went wrong.' What is the primary benefit of emitting an error event in this scenario?
The primary benefit of emitting an *error event* is to allow for robust error handling and retry mechanisms. By explicitly signaling a failure during authentication, downstream systems can implement strategies for dealing with the error – potentially retrying the login or taking alternative actions. Simply reducing event volume isn't sufficient; you need to handle the failure appropriately.
22 / 22
A junior developer, Chloe, is creating a PR for an e-commerce system. She's using event storming and has identified a 'CheckoutCompleted' event. When asked about its potential integration with the order management system, she says: 'We need to ensure that this event triggers a *saga* to handle all the dependent services.' What does Chloe mean by 'saga'?
Chloe is referring to a *saga* as a sequence of local transactions designed to achieve an overall business goal. In event-driven systems, sagas are crucial for managing complex operations that involve multiple services – ensuring eventual consistency even if individual steps fail. Each transaction within the saga will have compensating actions to undo its effects if necessary.
Frequently Asked Questions
What does the "Event Storming — Vocabulary — Event-Driven Architecture | CoderLingo" exercise cover?
Learn the vocabulary of event storming workshops: domain events, commands, aggregates, policies, and hotspots.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Event Storming — Vocabulary — Event-Driven Architecture | CoderLingo"?
This exercise has 22 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Event-Driven Architecture Language exercises?
Browse the full Event-Driven Architecture Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.