One to many, relationship in this lecture underscores two patterns open house surveys and the published
language pattern in the one to many relationship upstream bounded contacts referred to as Provida offers
common services to two or more bounded contexts.
In this example, Inbee are the downstream bounded context and C is the upstream boundary context,
which is offering common services to.
And B the common integration models are defined by the bounded context.
C With no regard to the needs of A or B the downstream bounded context may decide to conform or use
the athea.
So in this example here is A conformist, whereas B is using the anti-corruption layer.
These decisions are made by the teams who work on these bounded context independently.
The upstream boundary context that provides the common services is referred to as the open source service,
and this pattern is referred to as the open source service pattern to depict this common service as
pattern which is placed in front of the upstream bounded context that provides the common services,
the upstream bounded context or the open hosted service provider in this relationship offers a common
language for integration.
This common language is accepted by the teams working on the downstream bounded context.
This common language is referred to as the published language, and this pattern is referred to as the
published language pattern.
The use of published language is depicted by placing a APL in front of the upstream alongside the Oireachtas.
So this context mapping depicts a scenario where C is providing common services.
That is, it has the Oireachtas provider and also has a published language.
Let's call it an example of common services realisation.
The functionality is exposed by way of which has bounded contexts, and it is well accepted by the downstream
bounded context.
So think of a team that creates a service which exposes gaps.
And lets say this team is also publishing the rest API models and schemas by way of open API specifications
or Swagga specifications.
Other teams may build their own services by using these recipes, and they will build these recipes
by referring the open AP specifications for the apps and the schemas.
And looking at this diagram, you may say that you are already creating your APIs exactly in this manner
and you are absolutely right.
There is no difference in this lesson.
You learned about two patterns related to one to many relationship.
The first partners, the open hosted service pattern in which the upstream blended context provides
a set of common services or common capabilities to the downstream bounded context.
The second one is the published language, which goes hand-in-hand with the open hosted service.
Back on the upstream, bounded contacts on the open hosted service provider exposes the common language
for the common services, and this language is managed by the team responsible for the open hosted service,
the downstream bounded contacts except this published language.