What are Bounded Contexts and Context Maps in Domain Driven Design?
One of the big problems with approaching a topic like Domain Driven Design is the wealth of new ideas, patterns and terminology you need to get your head around.
This can often mean that a topic is unapproachable or overwhelming because you feel like you are drowning in too much information.
Last week we looked at the What is the Domain Model, what it means and how to think about it as part of an application.
This week we’re going to be looking at two more parts of the Domain Driven Design terminology in Bounded Contexts and Context Maps.
What is the Domain Model?
The Domain Model is the structured knowledge that is related to a specific problem. The Domain Model itself could be code, written prose or a diagram, the medium itself is not really important.
The Domain Model focuses its attention on a specific problem. This constraint forces you to really get at the heart of the problem whilst ignoring everything from the outside world.
This means that the Domain Model will have it’s own internal language that represents the important things that are specific to that one problem.
If you are new to the idea of a Domain Model, I would recommend that you read last week’s post before continuing with this one.
The real world of coexisting Domain Models
The theoretical idea of a Domain Model makes a lot of sense in the world of programming. A Domain Model is the focused knowledge of a problem and so having a clear depiction of the problem and the solution makes your life as a programmer a lot easier.
Having a single model is a noble goal because a single unified model is, in theory, easier to get your head around.
However, in the real world of building applications for businesses, there is never just a single Domain Model. If you were building an application that touches many parts of an existing business, you will likely encounter multiple coexisting Domain Models that will often contradict one another.
For example, in a typical ecommerce web application, the term Product will likely mean something different in the stock system than it does in the catalogue system. This might mean that the two different systems have two different ideas of responsibility for that object, or that the object should have two completely different sets of capabilities.
When objects have multiple different responsibilities for different parts of an application they can become monolithic and difficult to work with. Whats more, when there are multiple developers working on different problems using the same objects, there will inevitably be conflicting requirements and the introduction of unforeseen bugs and inconsistencies.
A Domain Model should be the focused knowledge around a particular problem. This constrains the scope of the Domain Model to a very specific context. When you inevitably encounter these conflicting ideas, it’s time to take a step back from the Domain Model.
What is a Bounded Context?
A Bounded Context is the boundary that surrounds a particular model. This keeps the knowledge inside the boundary consistent whilst ignoring the noise from the outside world.
This is beneficial for a number of reasons.
Firstly you can model the aspects of the problem without having to be concerned with other parts of the business. Using the example from earlier, a Product object within the stock system only needs to be concerned with the methods and properties of that single system, rather than any other business concern that happens to fit on an object called Product.
Secondly the terminology within a Bounded Context can have single, clear definition that accurately describe the problem at hand. Different departments across a company will usually have slightly different ideas and definitions of similar terms, but this can often derail a project through a lack of clarity and understanding when terms are mixed.
What is a Context Map?
When you start to think about the various subsystems of an application as individual Bounded Contexts, you can lose sight of the global view of the business as a whole.
It is inevitable that the various Bounded Contexts of an application will need to communicate or share data between each other.
A Context Map is the global view of the application as a whole. Each Bounded Context fits within the Context Map to show how they should communicate amongst each other and how data should be shared.
Conclusion
Bounded Context are a very important modelling tool when it comes to Domain Driven Development.
Bounded Contexts allow you to split a big problem into much smaller problems so you can focus on particular aspects of the application whilst ignoring everything else.
This allows you to form a consistent language around that specific problem so that everyone has a clear definition of each of the important terms.
Typically there will be certain objects in a web application that have different definitions in different context of the application. By splitting the application into Bounded Context, you ensure that the lines between each context are clearly defined so that the terminology around ideas and concepts of the application are clearly understood.
However when you focus on the minutia, you can often lose sight of the bigger picture of the application. A Context Map should show where each Bounded Context sits in relation to the others. There is often a lot of important information in the associations of Bounded Contexts and so a Context Map ensures that knowledge does not fall through the gaps.
Source: Taming Complex Domains with Domain Driven Design .
Source: Discovering the Domain Architecture .
Source: Strategic Domain Driven Design with Context Mapping .
Source: Domain-Driven Design .
One of the big problems with approaching a topic like Domain Driven Design is the wealth of new ideas, patterns and terminology you need to get your head around.
This can often mean that a topic is unapproachable or overwhelming because you feel like you are drowning in too much information.
Last week we looked at the What is the Domain Model, what it means and how to think about it as part of an application.
This week we’re going to be looking at two more parts of the Domain Driven Design terminology in Bounded Contexts and Context Maps.
What is the Domain Model?
The Domain Model is the structured knowledge that is related to a specific problem. The Domain Model itself could be code, written prose or a diagram, the medium itself is not really important.
The Domain Model focuses its attention on a specific problem. This constraint forces you to really get at the heart of the problem whilst ignoring everything from the outside world.
This means that the Domain Model will have it’s own internal language that represents the important things that are specific to that one problem.
If you are new to the idea of a Domain Model, I would recommend that you read last week’s post before continuing with this one.
The real world of coexisting Domain Models
The theoretical idea of a Domain Model makes a lot of sense in the world of programming. A Domain Model is the focused knowledge of a problem and so having a clear depiction of the problem and the solution makes your life as a programmer a lot easier.
Having a single model is a noble goal because a single unified model is, in theory, easier to get your head around.
However, in the real world of building applications for businesses, there is never just a single Domain Model. If you were building an application that touches many parts of an existing business, you will likely encounter multiple coexisting Domain Models that will often contradict one another.
For example, in a typical ecommerce web application, the term Product will likely mean something different in the stock system than it does in the catalogue system. This might mean that the two different systems have two different ideas of responsibility for that object, or that the object should have two completely different sets of capabilities.
When objects have multiple different responsibilities for different parts of an application they can become monolithic and difficult to work with. Whats more, when there are multiple developers working on different problems using the same objects, there will inevitably be conflicting requirements and the introduction of unforeseen bugs and inconsistencies.
A Domain Model should be the focused knowledge around a particular problem. This constrains the scope of the Domain Model to a very specific context. When you inevitably encounter these conflicting ideas, it’s time to take a step back from the Domain Model.
What is a Bounded Context?
A Bounded Context is the boundary that surrounds a particular model. This keeps the knowledge inside the boundary consistent whilst ignoring the noise from the outside world.
This is beneficial for a number of reasons.
Firstly you can model the aspects of the problem without having to be concerned with other parts of the business. Using the example from earlier, a Product object within the stock system only needs to be concerned with the methods and properties of that single system, rather than any other business concern that happens to fit on an object called Product.
Secondly the terminology within a Bounded Context can have single, clear definition that accurately describe the problem at hand. Different departments across a company will usually have slightly different ideas and definitions of similar terms, but this can often derail a project through a lack of clarity and understanding when terms are mixed.
What is a Context Map?
When you start to think about the various subsystems of an application as individual Bounded Contexts, you can lose sight of the global view of the business as a whole.
It is inevitable that the various Bounded Contexts of an application will need to communicate or share data between each other.
A Context Map is the global view of the application as a whole. Each Bounded Context fits within the Context Map to show how they should communicate amongst each other and how data should be shared.
Conclusion
Bounded Context are a very important modelling tool when it comes to Domain Driven Development.
Bounded Contexts allow you to split a big problem into much smaller problems so you can focus on particular aspects of the application whilst ignoring everything else.
This allows you to form a consistent language around that specific problem so that everyone has a clear definition of each of the important terms.
Typically there will be certain objects in a web application that have different definitions in different context of the application. By splitting the application into Bounded Context, you ensure that the lines between each context are clearly defined so that the terminology around ideas and concepts of the application are clearly understood.
However when you focus on the minutia, you can often lose sight of the bigger picture of the application. A Context Map should show where each Bounded Context sits in relation to the others. There is often a lot of important information in the associations of Bounded Contexts and so a Context Map ensures that knowledge does not fall through the gaps.
Domain-Driven Design. Context Maps
by Jose on July 27, 2016
In the previous post we saw the first strategic steps and how we disgregating the complexity of the business in Domains, Subdomains and Bounded Contexts .
Each Bounded Context contains or has the technology, programming language and minimum architecture necessary to satisfy the business requirements of its context through a domain model . The existing relationships between Bounded Contexts are called Context Maps and the rules necessary to map / translate a domain model from one context to another: Translation Map .
Once the Bounded Contexts have been identified , we must establish the type of relationship between them according to the needs of each case, marking the direction of information flow through U pstream(service exposure) and D ownstream (consumer of services):
Evans, describes organizational patterns and integration that describe the types of relationship between Bonded Contexts
Partnership: Both Downstream and Upstream teams have a strong and close dependence, it being necessary to jointly plan and synchronize the updates of both Bounded Contexts . The development must take into account the needs of both contexts through an exhaustive coordination between the teams.
Shared Kernel: Bounded Contexts that share / reuse part of the domain model, existing an interdependency or a shared common area. These shared elements should not be modified without consulting the affected teams:
Source: Taming Complex Domains with Domain Driven Design .
Customer-Supplier Development: A team manages the services of the Bounded Context ( Upstream ) giving support on demand according to the needs of the team that manages the Bounded Context that requests the resources ( Downstream ). The exhibition of services is prioritized and negotiated beforehand to avoid dependencies in the evolution of the developments of the equipment that consumes them.
Conformist: The team manages and publishes the services ( Upstream ) in the Bounded Context in a misaligned way with the evolution of any other context. The team that manages the consumer Bounded Context (Downstream) adheres and conforms with the modeling represented in the services, without the need to make them compatible with local / own domain modeling.
Source: Discovering the Domain Architecture .
Separate Ways: Independent Bounded Context without any relationship between any other. There are no integrations or relationships of any kind between the development teams.
Bif Ball of Mud: Monolith or Legacy Code not disintegrated encapsulated / isolated in a Bounded Contextsharing its services. Controlling its growth and advising extracting it in new Bounded Context generating new Context Maps among existing ones.
Technical integration patterns between Bounded Contexts
Open Host Service (OHS): Defines a protocol for access to the system or services for the integration of requirements. Normally you need a common publishing language for interaction between the domain models. For example, RPC or REST through API . Although it can be implemented through a messaging middleware like RabbitMQ .
Published Language (PL): Common language for translation between the models that will interact. For example, JSON or XML . Normally associated with OHS. The advantage of using REST services is that in each request the PL can be specified by configuring the desired content type .
Anticorruption Layer (ACL): Isolated layer that manages the mapping or translations between the domain models of the Bounded Contexts to maintain compatibility between them.
Source: Strategic Domain Driven Design with Context Mapping .
In this layer, the exposed interfaces are implemented as domain services . Both the Adapter and the Translator of each entity of the model that we want to translate or make compatible. Using Facade and using HttpClient :
Source: Domain-Driven Design .
Adapter can be replaced by new implementations of Repository using HttpClient for access to the external repository via API.
In the following diagram we see the Bounded Contexts and their integration points using OHS and PLusing ACL to map and translate the domain model establishing compatibility for each type of entity:
Graphic summary of all concepts:
So far, I'm going to take it up to Chapter 5 of Implementing Domain-Driven Design by Vaughn Vernon. The rest is focused on the tactical aspects of DDD: Entities, Value Objects, Services, Domain Events, Modules, Aggregates, Factories, Repositories, etc.
It will be more fun 
Coming soon ...
Coming soon ...
Do you think there is some important strategic aspect in DDD that I do not mention in both post and should?
Do you have any experience breaking up a Big Ball of Mud in Bounded Contexts?
No comments:
Post a Comment