Building Information Systems with Event Modeling

Build information system automation as collaborative practice through Event Modeling. With Domain events, modeling is easy to identify where we are crossing a boundary between two different components. Boundaries across contexts are defined by the messages they send. When the boundaries around components are visible, assigning owners to each element is easier. You need to understand that a lot of rules and a lot of things need to be clarified. In temporal modeling, we are more interested in what’s going on, what changes, and the interactions between different actors. That’s why we use something like even storming. It would be best if you enforced the timeline. Of course, make all the rules explicit and explain the domain event.

When you start modeling events, it forces you to think about the system’s behavior. Domain events represent the state in time of a business process. Publishing *domain events* out of a bounded context is the most robust approach to integration between sub-domains. 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.

A *domain event* is anything that happens that is of interest to a domain expert. Domain events capture those facts in a way that doesn’t specify a particular implementation. They must learn, define, refine, and use it only in conversations about the model. Domain events are thus a more stable and resilient scaffolding for your model.

Bounded Context. A Bounded context represents data and behavior in the code-base. The interface to communicate between bounded contexts is the events. Bounded contexts use Domain events to decouple the communication. Domain events]should have a simple interface to share with the rest of the application. Domain events create a trackable sequence of facts that lead to the system’s current state.

Think about Domain events as facts. The intention of what happened is expressed in naming the Domain events, e.g., *The user registered by email or joined Facebook*.

Data is private, and publishers publish their demands as the interface to communicate, which is public. Consumers can store whatever they need in their data, duplicating it. Still, the other context requires only parts of their information, only some things. Domain events are the interface for communication in an application. When you start publishing the domain events, the events become the interface between modules.