Earlier in the article Software Architecture Patterns we briefly discussed domain driven design. In this article we will take a real example and dive into best practices and design of solution based on hypothetical problem or scenario.
Bounded Context is a central pattern in Domain-Driven Design and It is the focus of DDD’s strategic design section which is all about dealing with large models and teams. The DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
Strategic design deals with situations that arise in complex systems, larger organizations, interactions with external system.Strategic design decisions are made by teams, or even between teams. Strategic design enables the goals of DDD to be realized on a larger scale, for a big system or in an application that fits in an enterprise-wide network.
DDD is about designing software based on models of the underlying domain. A model acts as a Ubiquitous language to help communication between software developers and domain experts. It also acts as the conceptual foundation for the design of the software itself.
It is hard to model a larger domain and build a single unified model. In real world, small domain models are build and together they represent the larger domain. Now lets image a real world example from electricity utility – smart meters ! – here the word “meter” meant subtly different things to different domain experts coming from different parts of the organization. Lets try to understand the domain and try to break into sub domain models.
Smart meters are the next generation of gas and electricity meters and offer a range of intelligent functions.The smart metering system is made up of: one electricity smart meter, one gas smart meter, a communications hub and an in-home display unit-the smart energy monitor on which you can view your energy.Smart meters measure actual, total gas and electricity usage and put consumers in control of their energy use, allowing them to adopt energy efficiency measures that can help save money on their energy bills.
Now lets split the into domains and sub domains
In the above diagram the subdomain build on foundation however one sub domain is interrelated to one or more other sub domain. They don’t exists in isolation in real world. The total unification of the domain model for a large system will not be feasible. So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model.
A bounded context typically represents a slice of the overall system with clearly defined boundaries separating it from other bounded contexts within the system. If a bounded context is implemented by following the DDD approach, the bounded context will have its own domain model and its own ubiquitous language.
A bounded context is the context for one particular domain model. Similarly, each bounded context (if implemented following the DDD approach) has its own ubiquitous language, or at least its own dialect of the domain’s ubiquitous language, entities, services etc. as shown below.
Bounded Contexts have both unrelated concepts – such as a support ticket only existing in a customer support context, but also share concepts such as products and customers both exists in sales and support contexts.
A large complex system can have multiple bounded contexts that interact with one another in various ways. A context map is the documentation that describes the relationships between these bounded contexts. It might be in the form of diagrams, tables, or text.
In the next series we will dive into how we can apply CRQS (Command Query Responsibility Segregation Pattern) and vertically slice the layered architecture to deliver the highly scalable yet composite solution.
Pixytech 