Design Cost-Effective Systems with Event Modeling
Events happen in a system — whether we store them or not that’s a choice. We begin by designing the screen that a user will see. The table representation is represented by a set of swim lanes corresponding to records — or rows. This allows us to see where data is updated, inserted, deleted, and attached to different workflow steps. We may show some of the user’s entered information. It’s essential to show exactly where this information is coming from. This allows us to show where each workflow step has its dependencies. Being efficient with storage requires re-opening the design of existing tables as we add new features to our system. This rework handles features costing more as the size of the whole system grows. The scapegoat of modern approaches like Agile, Waterfall is a name given to doing too much planning, so we need to get going sooner.
Event Modeling is the idea that we make it small by focusing on the essential parts of the design only. What happens when we update information? It is deleted. We lose a piece of history that may be crucial in helping us troubleshoot issues in our solution. The event model shows where we have these losses. Let’s discuss whether we should account for the history of some more essential records — or if it’s worth it to switch to a loss-less store. This would be more technical compared to the event model of event-sourced systems. That may be true, but what is the cost of all organizational roles to understand where the information they deal with is located?
Event Modeling enables a dedicated collaborative approach to software design. Event modeling describes the system based on the system’s transition within time. Think of event modeling as a storyboard. The team is making a movie about the procedure. The sequence of scenes is a walk-through of what the design looks like. Event Modeling enables collaboration by making everybody responsible for the whole system. Domain events represent a sequence of outcomes in a timeline. Domain events represent facts that establish the current state of the entire business process. Event modeling is natural to progress alongside business and account for what happened.
The Event modeled system decouples the Business infrastructure. The event model represents the user’s intention independent of the technology used in the background. Businesses working off event-modeled solutions enjoy the manipulation of historical data. The idea is to store the essential pieces of business information. Such data enables the ability to infer the system state at any given time.
Event Modeling describes systems using an example of how information changes across time. All the events in a timeline describe the system’s behavior. These are the events on the timeline that form the description of the system. Systems implementing an event model track most customer intent relevant to the business through Domain events. Suppose you concentrate on the state and have a place for each piece and where it will go. In that case, you reduce that rework to the point where you can follow the open-close principle almost to the letter. It’s a more collaborative approach and more dedicated. It’s like a small design instead of an extensive one up front, so we can do everything that UML was trying to do without all the complexity and details. We must consider which algorithms will use and how the code will behave. The green field project, the first two weeks first two months are lovely. We’re looking at what is the state of the system. We don’t care what happens when we press that button. We know that we intend to register and only store the fact that we’re registered. Whether this is running in Scala or Kotlin or whatever Language is immaterial. What matters is that if we shut the power off after that happened, the truth is stored in the system. Hence, the more system, the more pieces interact, and the more relationships you have to analyze.
Storytelling enables humans to pass knowledge on to the next generations and relies on how we store memories. We can show, by example, what a system is supposed to do from start to finish, on a timeline, and with no branching — again, to use that memory aspect of our brains. To do this, we need to draw a line with a specific timeline representing the different changes in the state across time. Why time? Time is an essential aspect of systems because every application is a distributed system in the scene. Now everything needs to work across continents. So, time is quite a necessary aspect of development.
A model that works supports the stakeholders and also the delivery team. Since event modeling describes a system’s behavior, representing the model in this way is ideal. Having different models to explain the same idea creates a lot of ambiguity. Making a model that works for the whole team implies removing all ambiguity for the abstract model.
[¹]: Implementing Domain-Driven Design
[²]: Event Modeling
