Symmetric relationship in this lesson, you learned about three new strategic patterns, separate ways,
partnership pattern and the shared kernel pattern, there may be a scenario where the bonded contacts
in a system has no relationship with other bonded contacts.
In such a scenario, the bonded contacts are truly independent or autonomous.
Consider the scenario where we have two bonded contacts and B which have no relationship.
What that means is that there is no sharing of models between these two bonded contacts since their
independent teams can work on these two bonded contacts autonomously.
In other words, these teams do not have to collaborate or coordinate for any task.
Now, some would argue that there are opportunities to reuse parts of A and B or vice versa.
But one has to consider the tradeoff.
And the tradeoff is that if there is reuse, then there will be a loss of autonomy.
So of go a little deeper.
Let's say there is a model and a that is shared by B, no, the teams cannot work autonomously y because
if it has to change the model, then the team for B will need to agree to the changes.
And that is a concern regarding the reuse.
There's no relationship between the boundary contacts is referred to as the separate ways pattern from
the realization perspective.
What that means is that they will be independent set of applications or services for each of the bonded
contacts.
For example, in the case of banking, we have the credit cards and home loans that have no relationship.
In that case, teams will independently develop applications and services for these two bonded contacts.
And what that means is that these two teams can work independently at their own pace to meet the business
goals of their respective business unit.
Sometime you find bounded contacts that have mutual dependency on each other.
This kind of relationship between the bonded contacts is referred to as the symmetric relationship or
bidirectional dependency could be a symmetric relationship, a solid lightless place between the bonded
contacts.
This mutual dependency leads to a high level of coupling between the bonded context and this type of
relationship is referred to as the Partnership Parathion and Demand-Driven Design.
From the realization perspective, the partnership pattern translates into services that have mutual
dependencies.
So what that means is that the services may be developed by different teams, but because of the mutual
dependencies between the services, the teams cannot operate independently.
Not only that, each of the teams engage in this kind of relationship would need to learn the business
models and that ubiquitous language for the bonded contacts managed by the other team.
At the end of the day, what this means is that the teams in this kind of relationship will need to
coordinate their changes, deployments and releases, and that will defeat the purpose of adopting micro
services architecture.
Now, the obvious question you may have at this point is how do we solve this problem?
One way of solving this problem is to demarcate the boundaries for the shared models.
So let's say two independent teams are working on the blended context and voluntary context.
B, they can create a demarcation around the models that are shared between the two bonded contacts.
The idea is to manage these shared models independent of the rest of the bonded context.
So what that means is that if it needs a change and this change is not part of the shared models, then
the team assigned to bounded contacts, it can make independent decisions.
Similarly, if there are changes needed outside of the shared models and bounded contacts, be the team
assigned to bonder contacts.
B can make those decisions independently.
But at any point, if there is a need for making a change to the shared models, then the two teams
will coordinate.
The sharing of models between the bounded contacts is referred to as the shared goal pattern.
The important thing to keep in mind for the shared Carneal is that the overlapping parts of the contacts
represent the shared domain model, the shared concepts and the shared business language between the
two bonded contacts.
Typically, the shared kernel is realized by way of shared Labrys, such as Java, Java, Python Packages
and Ruby Gems.
Teams can independently develop services that use these shared libraries.
It is OK for the teams to use shared kernel and the shared Labrys as long as the scope of sharing.
Between the bonder contacts is limited to a small set of models for scenarios involving sharing of too
many models between the bonded contacts, it becomes difficult to maintain the integrity of the boundaries
of the boundary contacts.
And that is the reason for the suggestion to use shared kernel only if we are talking about a small
set of shared concepts between the bounded contacts.
In this lesson, I covered three strategic patterns for.
The first one is the separate ways in which there is no relationship between the bounded contacts.
As a result, the teams working on the two bonded contacts can work truly independently.
The next one is the partnership pattern in which there are interdependencies between the bounded contacts.
As a result, teams must coordinate with each other to make changes to their own bounded contacts.
The third one is the shared Kamna, in which it is suggested that the boundaries of the shared concepts
and models be clearly demarcated, and only the changes to these shared models need to be coordinated
by the teams.
In other words, if the team is working on changes that are not related to the shared models or concepts,
then it can carry out those changes without needing input from the other team.