Communication across bounded contexts
Before we start...
Bounded Context
It is part of the Strategic Pattern of the DDD methodology and it represents a logical boundary where the rules of a sub-domain are applied and make your context unique
Sub-Domains
Core: is a part of the business that is of primary importance to the success of the organization.
Supporting: is a part of the business that is essential, but yet not Core.
Generic: is a part of the business that looks like a supporting subdomains but it is not specialized.
Contexts
The circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood.
" The first result of a Google search
Why context matters?
Office
Shower
Be naked in:
Nude Beach
Non-Nude Beach
Context may looks similar but...
Be naked in:
A domain visualization
Context map
9 ways to communicate across contexts
(9 ways to co-operate across contexts)
- Partnership
- Shared Kernel
- Customer-Supplier Development
- Conformist
- Anticorruption layer
- Open Host Service
- Published Language
- Separate ways
- Big ball of mud
Partnership
When teams in two Contexts will succeed or fail together, a cooperative relationship needs to emerge. The teams institute a process for coordinated planning of development and joint management of integration. The teams must cooperate on the evolution of their interfaces to accommodate the development needs of both systems. Interdependent features should be scheduled so that they are completed for the same release.
Vaughn Vernon - IDDD
Context A
Context B
Team A
Team B
Shared Kernel
Sharing part of the model and associated code forms a very intimate interdependency, which can leverage design work or undermine it.
Designate with an explicit boundary some subset of the domain model that the teams agree to share.
Keep the kernel small.
This explicit shared stuff has special status and shouldn’t be changed without consultation with the other team. Define a continuous integration process that will keep the kernel model tight and align the Ubiquitous Language of the teams.
Vaughn Vernon - IDDD
Shared
Model
Context A
Context B
Customer-Supplier Development
When two teams are in an upstream-downstream relationship, where the upstream team may succeed interdependently of the fate of the downstream team, the needs of the downstream team come to be addressed in a variety of ways with a wide range of consequences. Downstream priorities factor into upstream planning. Negotiate and budget tasks for downstream requirements so that everyone understands the commitment and schedule.
Vaughn Vernon - IDDD
Context A
Context B
Team A
Team B
Upstream
Downstream
Context A
Context B
Team A
Team B
Upstream
Downstream
Conformist
When two development teams have an upstream/downstream relationship in which the upstream team has no motivation to provide for the downstream team’s needs, the downstream team is helpless. Altruism may motivate upstream developers to make promises, but they are unlikely to be fulfilled. The downstream team eliminates the complexity of translation between bounded contexts by slavishly adhering to the model of the upstream team.
Vaughn Vernon - IDDD
Context A
Context B
Team A
Team B
Upstream
Downstream
Anticorruption layer
Translation layers can be simple, even elegant, when bridging well-designed Bounded Contexts with cooperative teams.
But when control or communication is not adequate to pull off a shared kernel, partner, or customer-supplier relationship, translation becomes more complex.
This layer talks to the other system through its existing interface, requiring little or no modification to the other system.
Internally, the layer translates in one or both directions as necessary between the two models.
Vaughn Vernon - IDDD
Context A
Context B
Team A
Team B
Upstream
Downstream
ACL
Open Host Service
Define a protocol that gives access to your subsystem as a set of services. Open the protocol so that all who need to integrate with you can use it. Enhance and expand the protocol to handle new integration requirements, except when a single team has idiosyncratic needs. Then, use a one-off translator to augment the protocol for that special case so that the shared protocol can stay simple and coherent.
Vaughn Vernon - IDDD
Context A
Context B
Team A
Team B
Upstream
Downstream
Context C
Context D
Downstream
Downstream
Team C
Team D
Published Language
The translation between the models of two Bounded Contexts requires a common language. Use a well-documented shared language that can express the necessary domain information as a common medium of communication, translating as necessary into and out of that language. Published Language is often combined with Open Host Service.
Vaughn Vernon - IDDD
What does change?
Context A
Context B
Team A
Team B
Upstream
Downstream
Context C
Context D
Downstream
Downstream
Team C
Team D
Separate ways
We must be ruthless when it comes to defining requirements. If two sets of functionality have no significant relationship, they can be completely cut loose from each other. Integration is always expensive, and sometimes the benefit is small. Declare a bounded context to have no connection to the others at all, enabling developers to find simple, specialized solutions within this small scope.
Vaughn Vernon - IDDD
Context A
Context B
Team A
Team B
Big Ball of Mud
As we survey existing systems, we find that, in fact, there are parts of systems, often large ones, where models are mixed and boundaries are inconsistent. Draw a boundary around the entire mess and designate it a Big Ball of Mud. Do not try to apply sophisticated modeling within this Context. Be alert to the tendency for such systems to sprawl into other Contexts.
Vaughn Vernon - IDDD
Big ball of mud
Contexts
Team A,B,C,D,G..Z
Other teams
The less, the better
Questions?
Links and Books
Implementing DDD
http://bit.ly/dp-iddd
DDD Distilled
http://bit.ly/dp-dddd
DDD (blue)
http://bit.ly/dp-ddd