Event-First Thinking for Resilient Systems
When you start modeling events, it forces you to think about the system’s behavior instead of its structure. Domain events represent the state in time of a business process. Customer interactions determine at a higher level what is essential to the business. Events are defined based on customer-facing interactions. The event represents an agreement of something after a particular action is executed.
In the same way, internal to the application, the contract is enforced across different sub-domains. Other sub-domains react to events, and that’s how collaboration happens. Publishing *domain events* out of a bounded context is the most robust approach to integration between sub-domains.
A domain event is anything that happens that is of interest to a domain expert. The domain expert is interested in something other than databases, web sockets, or design patterns. They are interested in the business domain of the things that must happen. Domain events capture those facts in a way that doesn’t specify a particular implementation. Domain events are thus a more stable and resilient scaffolding for your model. Limiting the initial discussions to domain events forces everyone to focus on the ubiquitous language of the domain. They must learn, define, refine, and use it only in conversations about the model.
Domain events should be, Atomic: something happened (bid on an item, send an email, device temperature). Related: a stream or sequence of events (tracking a pricing change, device metrics changes over time). Behavioral: the accumulation of facts captures behavior. Understanding who requires a particular state change leads to identifying collaborators and dependencies.
Domain events can be named using the name of the entity that changed state, followed by the action that happened in the past tense. Such as a Proposal followed by a verb in the past tense. e.g., ProposalDenied, ProposalApproved. The event exposes information about its namespace. Any component that is interested in the event can subscribe to it. Naming Domain events in this way focus on business operations rather than technical concerns.
Event-first thinking changes how you think about what you are building. Capture facts. Capture behavior. Provide a representation of the real world. Model use cases of how. Supports repeated evaluation and processing (a time machine). Provide horizontal scaling. Speak the same language as the business. The approach is unique in that it processes the event as a reaction. The emitter doesn’t call on a specific function; the API has been removed and instead sends an event. Don’t do anything else, emit events, and have no API coupling to any service.
