About this Guide > Strategic Patterns > Relationships

Relationships

Relationships between Bounded Contexts

Bounded Contexts are independent but NOT isolated from other BCs around them; models in BCs collaborate to fulfil requirements of a system. Recall that Domain Driven Design approach leads to smaller independent domain models that can then be built as highly decoupled, independent set of microservices.

It is important to ensure that these relationships do not impact the integrity of the bounded context i.e., increase coupling or dependencies between bounded context.

relationship-types

Each bounded context is translated into one or more microservices
Relationships or dependency between bounded context translates into inter-dependency between microservices
Which in turn leads to inter-dependency between teams owning the microservices!!! which is opposite of what we are trying to achieve with DDD !!!

In this lesson you will learn strategic patterns for managing the bounded context relationships. At the end of this lesson, you will see an example model for a bank with appropropriate patterns in use.

Anti-Pattern : Big Ball of Mud

Refers to a poorly designed model. Too many inter-dependencies between bounded contexts leading to fuzzying of the domain context boundaries

Haphazardly structured model
That leads to spaghetti-code
Mostly created by unregulated growth | fixes over time

Pattern : Context Map

Document the relationship between the bounded contexts. There are multiple patterns based on the relationship and degree of dependency between bounded context.

Separate ways

The BCs are truly Independent of each other. Opportunity to Re-use may exist but “loss of autonomy” is a concern !!!

Teams work at their own pace to meet the business goals !!!

separate-ways

Patterns : Shared Kernel

In case of Symmetric (a.k.a. bidirectional) relationship between the bounded contexts are dependent on each other. Each team needs to learn the business model and ubiquitous language of the other bounded context. There is high levels of coupling between the bounded contexts. Translates into Microservices that have mutual dependencies!!!

bidirectional-1

This kind of a relationship is addressed by way of a Shared Kernel pattern (a.k.a. Partnership pattern) that promotes use of shared models (and software assets).

Demarcate the boundaries for shared models. With this setup teams will need to coordinate changes needed for the shared model but rest of the changes are managed independently by each team.

bidirectional-2

Shared concepts/assets may be implemented as a shared library, API, Messaging interface. You may Consider extracting the kernel as separate BC

Assymetric Relationship

In this kind of a relationship, one BC depends on another BC. Instead of using an arrow to depict this dependency, as a convention letters U and D are used on each end of the line to depict the Upstream and Downstream end of relationship.

The Upstream bounded context is independent of the Downstream bounded context. The Downstream BC accepts models exposed by Upstream BC

asymmetric-upstream-downstream

The next set of patterns are to address the asymmetric relationships. Idea to leverage these patterns to make the dependencies more manageable.

Pattern : Conformist

This relationship describes the relationship of 2 bounded context, where the upstream has no interest in supporting the downstream for whatever reason. Instead, the downstream must conform to whatever the upstream provides. This can happen when integrating a new feature with a large, existing solution that is well established; or using a set of APIs, where the downstream is not the sole customer.

Conformist is also an upstream/downstream relationship between two bounded contexts. The difference is that the upstream system has no idea of the existence of the downstream and changes in this upstream are not demanded by the downstream, which means the downstream uses the upstream at its own risk. Usually this pattern is used in the short term for experimentation.

Depicted by using CF on the downstream end of the relationship

In this illustration the Credit cards team conforms to the Customer interface(s) (and model) exposed by the Customer management team.

conformist

Pattern: Anti-Corruption Layer

A Conformist can minimize the corruption of its domain model by isolating the model-dependencies from other bounded context.

Depicted by using ACL on the downstream end of the relationship

ACL holds knowledge of models from both ends of the relationship. It carries out the translation between the models.

acl

Pattern : Customer-Supplier

Its like a Client-Server, where in the server creates the interfaces based on the needs of the client. The team managing supplier bounded context will consult with the client team before making any changes to the model or interfaces.

customer-supplier

One-to-many Relationships

Upstream provider offers common services to other bounded contexts. In this illustration bounded contexts A and B are dependent on bounded context C. The teams owning the dependent bounded contexts can independently decide on the relationship pattern (Conformist, ACL) that they would apply to their bounded context. In certain scenarios, the upstream context provides a well defined set of common models and interfaces to the dependent contexts.

one-to-many

Pattern : Open Host Service

This is built on top of the Conformist approach from earlier, where the downstream is a lot more tolerable. The upstream will also need to provide version support. Typically the upstream bounded context will support multiple clients and have no interest in especially supporting particular one. For example, to conform to Amazon APIs, the downstream will have confidence in the integration by understanding the documentation Amazon provides.

Depicted by using OHS on the upstream end of the relationship

one-to-many