Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
Why is it a common, disciplined pattern for an aggregate to only RECORD domain events internally, publishing them separately after the aggregate has been successfully saved?
💻 Code Challenge | +75 XP
Implement an Order aggregate that internally records an OrderShipped domain event when ship() is called, with a pullEvents() method, and an application-layer function that saves the aggregate first and publishes its events only after the save succeeds.
A downstream analytics service occasionally received an OrderShipped event for an order that, due to a later validation failure, was never actually saved as shipped in the database. Reorder the steps to fix the ordering bug.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Publishing a domain event immediately when a business operation occurs, before confirming the corresponding state change was actually persisted successfully
// Wrong: published before persistence is confirmed
eventBus.emit("OrderShipped", order);
await orderRepository.save(order); // could still fail here!
// Correct: publish only after a successful save
await orderRepository.save(order);
for (const event of order.pullEvents()) await eventBus.publish(event);The Solution //
If the event is published before the save completes (or if the save subsequently fails), a subscriber may react to something that never actually happened from the system's durable point of view — for example, sending a shipping confirmation email for an order that failed to save as "shipped." Record events internally on the aggregate, and only publish them after the save has been confirmed successful.
The Error //
Naming domain events after low-level field changes rather than meaningful business occurrences
// Not meaningful — subscribers must inspect the payload to understand it
emitter.emit("OrderFieldUpdated", { field: "status", value: "shipped" });
// Meaningful — the event name alone tells you what happened
emitter.emit("OrderShipped", { orderId, trackingNumber });The Solution //
An event like "OrderFieldUpdated" carries no inherent business meaning and forces every subscriber to inspect the payload to figure out what actually happened, which defeats the self-documenting value domain events are meant to provide. Name events after specific, meaningful business occurrences instead.