I was reviewing some event-sourced system designs the other day, and a familiar pattern emerged: someone wanted to add a status field to an aggregate, then update that status across all the read models. It felt automatic, like muscle memory from years of CRUD thinking.
Status doesn’t mean the same thing to everyone.
The Sales Order That Tells Different Stories
Take a sales order. It might move through draft, open, fulfilling, in transit, shipped, delivered, invoiced. Seems straightforward, right?
Except the warehouse doesn’t care about most of those. They care about picking, picked, packaged, labeled. Six different statuses that matter deeply to them.
Billing doesn’t care until it’s delivered. That’s when they’re allowed to invoice. Everything before that moment is noise.
Accounts receivable might not care about the sales order at all. They care about the customer invoice, because that’s what goes in the general ledger.
Same sales order. Different contexts. Different meanings.
When Status Drives Decisions
A customer calls asking when their order will arrive. The seller sees “fulfillment” on the screen. That doesn’t tell them much. But if they see “picking,” they have a better sense of timing.
The question isn’t just “what’s the status?” It’s “who’s asking, and what decision are they trying to make?”
Same process. Different status. Different needs.
The Invoice-Before-Shipment Problem
Here’s where single-status thinking breaks down completely.
A business invoices before shipping. They print the invoice, put it in the package, and the truck driver delivers both together.
What’s the status now? Invoiced? Shipped? Both are true. If we only track the last change, we lose the story. The status field says “shipped,” but someone looking at it wonders, “Has it been invoiced?”
The events know the truth. We invoiced, then we shipped. We can build a read model that shows both, with timestamps, depending on who’s asking.
Building for Who’s Asking
When we think in terms of events instead of state changes, we can tailor what people see.
Logistics sees fulfillment-related events: picked, packaged, labeled, shipped.
Billing sees invoiced and delivered.
Customer support sees what they need to answer the customer’s next question: Can I still make changes? When will it arrive? What changes are allowed?
The customer might see a simplified version. The support person might see more detail, plus notes from the business owner: “If this customer asks for X, come talk to me first.”
Moving Past CRUD Habits
Coming from a CRUD mindset, we update the status field. The status changes from invoiced to shipped, and we lose information in the process.
When we pair event sourcing with domain-driven design, we ask: Does “status” mean the same thing across different contexts?
If the answer is no, we need to dig deeper. Who’s asking? Where? Why? What will they do with that answer?
When we know that, we can build read models that give people what they actually need, not just a single field that tries to mean everything to everyone.
What This Means for Design
This isn’t just about event sourcing. It’s about understanding that information serves different purposes for different people.
A status field is shorthand. It compresses a story into a single word. But different people need different stories.
When we design systems, we can ask: What decision is this person trying to make? What’s the next question they’ll ask? What action will they take?
Then we can build experiences that answer those questions directly, rather than having everyone interpret the same generic status field.
The conversations that uncover these needs are where better designs come from.
Leave a Reply