Ubiquitous Language
Friday, November 9, 2018
Context Map
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?
Bounded Context
BoundedContext
15 January 2014
Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
DDD is about designing software based on models of the underlying domain. A model acts as a UbiquitousLanguage to help communication between software developers and domain experts. It also acts as the conceptual foundation for the design of the software itself - how it's broken down into objects or functions. To be effective, a model needs to be unified - that is to be internally consistent so that there are no contradictions within it.
As you try to model a larger domain, it gets progressively harder to build a single unified model. Different groups of people will use subtly different vocabularies in different parts of a large organization. The precision of modeling rapidly runs into this, often leading to a lot of confusion. Typically this confusion focuses on the central concepts of the domain. Early in my career I worked with a electricity utility - here the word "meter" meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself (which could be replaced if faulty). These subtle polysemes could be smoothed over in conversation but not in the precise world of computers. Time and time again I see this confusion recur with polysemes like "Customer" and "Product".
In those younger days we were advised to build a unified model of the entire business, but DDD recognizes that we've learned that "total unification of the domain model for a large system will not be feasible or cost-effective" [1]. So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model - essentially a way of structuring MultipleCanonicalModels.
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). Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic concepts for integration. Several DDD patterns explore alternative relationships between contexts.
Various factors draw boundaries between contexts. Usually the dominant one is human culture, since models act as Ubiquitous Language, you need a different model when the language changes. You also find multiple contexts within the same domain context, such as the separation between in-memory and relational database models in a single application. This boundary is set by the different way we represent models.
DDD's strategic design goes on to describe a variety of ways that you have relationships between Bounded Contexts. It's usually worthwhile to depict these using a context map.
Further Reading
The canonical source for DDD is Eric Evans's book
. It isn't the easiest read in the software literature, but it's one of those books that amply repays a substantial investment. Bounded Context opens part IV (Strategic Design).
. It isn't the easiest read in the software literature, but it's one of those books that amply repays a substantial investment. Bounded Context opens part IV (Strategic Design).
Vaughn Vernon's Implementing Domain-Driven Design focuses on strategic design from the outset. Chapter 2 talks in detail about how a domain is divided into Bounded Contexts and Chapter 3 is the best source on drawing context maps.
focuses on strategic design from the outset. Chapter 2 talks in detail about how a domain is divided into Bounded Contexts and Chapter 3 is the best source on drawing context maps.
I love software books that are both old and still-relevant. One of my favorite such books is William Kent's Data and Reality. I still remember his short description of the polyseme of Oil Wells.
. I still remember his short description of the polyseme of Oil Wells.
Eric Evans describes how an explicit use of a bounded context can allow teams to graft new functionality in legacy systems using a bubble context. The example illustrates how related Bounded Contexts have similar yet distinct models and how you can map between them.
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.
Subscribe to:
Posts (Atom)