Modeling Bounded Context
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. Not supporting business sub-domains pushes the system’s architecture towards a random structure. Bounded context exposes concepts from a single domain. In this context, actors represent stakeholders or users from the real world. We want to partition the system so that a change to one actor does not affect the other. Actors are the people that interact with the system. The people we want to help influence their behavior through the usage of the application. These Actors direct change.
Example:
`Finance::Ordering`
Where `Finance` refers to the stakeholder or group of stakeholders who are getting the value from the solution. In the example above, the `Finance` department supports `Ordering` behavior. The `Ordering` team supports the behavioral change at the code level.
A Bounded context represents data and behavior in the code-base. Bounded contexts communicate using Domain events to decouple the communication. The interface to communicate between bounded contexts is the events. Domain events should have a simple interface to communicate with the rest of the application. Think about Domain events as facts. When you start publishing the domain events, the events become the interface between modules. 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. The other context usually only requires parts of their information. If you look into the data, you might wonder why it is the data in this way and not the other. What happened?
Domain events create a trackable sequence of facts that lead to the system’s current state. The prevention on the consumer side comes from the inversion of control. It would be best if you care about compatibility with the consumers. For example, the order was placed, or a new order line was added to the basket we published, and if it is interesting, they can react.
Events are the interface used for communication in an application. The events have some attributes, and he uses the interface to communicate with the rest of your applications.
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. Domain events are thus a more stable and resilient scaffolding for your 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.
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.
[¹]: Implementing Domain-Driven Design
[²]: Domain-Driven Design: Tackling Complexity in the Heart of Software
