Leveraging Domain-Driven Design for Effective Storytelling in System Development
When you start modeling events, it forces you to think about the system’s behavior. As opposed to thinking about the structure of the system. — Greg Young
Storytelling enables humans to pass knowledge on to the next generations and relies on how we store memories. 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.
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. The way that we as humans share information is through Storytelling. Storytelling is how we share knowledge. We present different scenarios as part of a specific situation to distill the wisdom and what happened to us. Our organic ledger is our memory. We use it to record what we are experiencing to retrieve information and make decisions in the future. The downside with memory, as opposed to a computer, is that we can cheat our memory. Our memories are not as reliable as a computer’s memory. Every time we retrieve a memory, we change it by connecting our recent experience with what we felt.
There are many benefits to keeping a ledger from a system’s perspective. A sequence of events represents the natural way of systems — digital or not. We make software systems behave to memory with Domain events. A computer can track every system’s final state down to the initial event that triggered everything. We save relevant information around a specific situation and then make decisions for the future base on what we learned.
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.
Domain-Driven Design models the ubiquitous Language per Bounded Context. A model can be anything that the people involved with the domain agree on.
The Ubiquitous Language is another way to represent a model. Ubiquitous Language is a common language between businesses and software developers. The Ubiquitous Language is a shared language developed by a team composed of domain experts and software developers.
A bounded context is a business domain, in the broad sense, is what an organization does and the world it does it in. A bounded context is a complete, well-defined business domain model. Bounded contexts are data and code. When using DDD, the goal is to create a Bounded Context. It is a desirable goal to align business sub-domains or departments one-to-one with Bounded Contexts.
At the implementation, level bounded contexts are deployable units of the Software. In Ruby, a Bounded context might be a gem. The internal structure of the gem can be defined with namespaces. e.g., `Sales,` `Marketing.`
Ubiquitous Language reflects the structure of the model. Not supporting business sub-domains pushes the system’s architecture towards a random structure. The systems that the model suggests should show up in the Software. We first need to gather data about the problem to make these associations. We should think about information systems in the same way. We need *data* and *rules* to process information. If we store data, then we will be able to apply more rules to it.
A model that works supports the stakeholders and also the delivery team. Since event modeling is about describing a system’s behavior representing the model in this way is ideal.
—
