Context mapping is another part of strategic design. Because when you're using domain-driven design, there's never only one bounded context in a single problem and solution space. have at least one new core domain, one new bounded context, and possibly another clean bounded context or legacy system. In this case, I'm showing that there are two new bounded contexts. One is underwriting and one is risk. Now, this line between the two bounded contexts does not necessarily represent a coupling between them. It can represent, there is some coupling between them, there is a dependency, but it doesn't mean that they are tightly coupled together. What is represented by that line is two things. First of all, the team relationships. What are the team relationships between these two teams that are working on the two different bounded contexts? And secondly, what is the integration style being used? How are we exchanging information between these bounded contexts? So keeping those two areas in mind, I'm going to now present several different context mapping patterns, what are known as software patterns, or ways of mapping context, bounded context, to work with each other. And some of these will represent team relationships, some of them technical relationships, and they are not mutually exclusive. The context mapping patterns that I will show you next can be used together. Overlapping. The first context mapping relationship is more of a team relationship. This is known as partnerships. Notice that there is a thick line between risk and rate. This context map or mapping is represented by a thick line because, as with any partnership, it requires a lot of communication, As with any partnership, it requires a lot of communication, a lot of planning, a lot of scheduling, a lot of meetings together, meetings that are supporting one another. And in essence, we say that a partnership means that one team does not have to say please to the other team when they need something. They are working that closely that they are supporting the needs of one another. Now, of course, it doesn't mean that we're intending to be impolite. That isn't the point. Of course, we can say please, but it's expected of each team to support the other because they will succeed or fail together. So it is an expensive relationship to maintain, and it could be that over time it would be advantageous to transition out of a partnership relationship into a different team relationship. This relationship is known as the shared kernel. This is where at least two bounded contexts share a common model between them. This means that they will each use the model that they share as if it were part of their own model. It will basically blend in to their own ubiquitous language. Therefore, terms and phrases and actions and so forth that are related to monetary, and risk does as well. This is actually not a very amiable relationship to be in sometimes. Because when you share a kernel, and again, I have to emphasize the word kernel means small. It's taken from the idea of an ear of corn, okay? And an ear of corn has maybe hundreds of these little berries on them or little pieces of fruit each one of those is known as a kernel of corn that tiny tiny yellow piece of vegetable that's on there and therefore a shared kernel is meant to be small some of the problems that you have with a shared kernel is meant to be small. Some of the problems that you have with a shared kernel is, first of all, you have to know that one team already has some kind of solution or shares the same motivation that you do for a certain area of the software. And secondly, that you as two teams can agree that the model that is to be shared should be a single definition and that you don't need separate definitions for each of the modeling elements. These are challenging problems to solve, actually, in many cases, because of lack of communication between teams, generally speaking, you will tend to not know the parts of models that other teams are using. And also, agreement is difficult, not because you tend to be disagreeable as individuals, but rather because each area of the business will tend to have quite different or at least partly different or partially different ideas about modeling concepts, such that monetary might be viewed differently as mental model in underwriting than it is from risk. But assume that because underwriting and risk are related to each other in some way, they do have conversations as teams. And because of their conversations, their dialogue between teams, underwriting learns that risk has a monetary part of their model that could be encapsulated and shared with another team, a la underwriting. Customer supplier is where there are two teams that have, one has a supplier function and the other functions as a consumer or a customer of the supplier. Note that in this case, risk is the supplier. It is said that risk is upstream from the customer. This means that the supplier does not know about the downstream consumer or customer. Rather, they supply some sort of interface for any downstream context or model to integrate with or through, and they don't really necessarily care who integrates with them because they have supplied some kind of interface that can be used by most integrators. And that puts the rate customer or consumer of the upstream risk context downstream, meaning that the influence flows from upstream to downstream. Therefore, rate will have to utilize what risk supplies to it. There may be some room for negotiation for getting new features on the interface that risk provides, but there's no guarantee that that will be possible or practical for the upstream risk team. They may have other priorities, other pressures that simply do not allow them to provide additional behavior interfaces to the downstream. So in essence, the downstream will generally have to accept what the upstream has or wait for some time frame in order to get more of what they need. A conformist relationship is where there is a complex upstream model. So you can think of this upstream again as being a supplier and the downstream as being a customer. But in this case, the customer is going to conform to the upstream model, as in it will consume the upstream model as it exists. They will not try to do any translation between languages. So the ubiquitous language, or at least a portion of the ubiquitous language that is in the upstream, will be consumed by the downstream. And as you can see, assessment results, which is in the upstream risk model, being the supplier, is consumed in rate the same way it is also using the assessment results. Thus, you will call this the conformist. And typically, where you will see conformacy or where a downstream team and model will conform to an upstream is, for example, complex third-party software. Let's say that you're using, you need to have a calendar provided for you or shared document capabilities, editing, and you decide to use the Google Workspace solutions for that. In the case of Google Workspace, the teams that integrate with that will likely not try to translate, for example, the upstream calendar interface and model elements into their own specialized, internally unique model elements. That's because there's just too much overhead in trying to keep up with any changes that the upstream will have, and generally speaking, the upstream may have a very good model that is simply worthy of reuse. model that is simply worthy of reuse. And while the downstream may have its own specialty areas of expertise in the model that they provide, they can simply conform to the parts of the upstream model that are necessary for them to use. The opposite of conformist is known as anti-corruption layer. This is where the downstream team will purposely translate from, let's say, a big ball of mud and the confusion that's going on in that upstream big ball of mud into a downstream result. So let's say that for a while, as we are newly developing this rate calculation interface, we're getting some information or much information from risk, which is also upstream, and we are conforming to risk to a degree, only in this case the assessment results. But notice that we are also integrating with this big ball of mud, which is upstream, but the red box ACL that's marked as ACL or anti-corruption layer is purposely translating from the fractured and confused model that exists upstream and translating any of those concepts into concepts that are clean and well-defined within the rate context. Sometimes you simply can't afford the time, the kind of investment that's needed for an anti-corruption layer, if it's very, very complex to do that. And in this case, there simply is no reason to have an anti-corruption layer between risk and rate because this one model concept of assessment results is very simple to conform to, whereas we do want to have a translation to keep the mud, so to speak, of the rate context. Open host service is a relationship that provides, actually it's an integration style as a team relationship that provides an API. provides an API. So the downstream uses an API to register for events that occur upstream. And therefore, events will flow to the downstream because they have registered through the API to receive event streams. through the API to receive event streams. So you can see that the upstream rate, once again, with the U attached or associated with it, showing that it is upstream, is supplying an API by which underwriting downstream, the analytics downstream, and the agents downstream are registering so that the domain events known as, in this case, rate calculated, can flow from the upstream to the downstream. An integration technique that is used often with, and generally speaking, with open host service is called published language. And this is where bounded contexts can publish to the outside world a kind of modeling language that they exchange, use to exchange data or information. And as you can see, the domain events, risk assessed, rate calculated, and quote generated, these are part of the published language of each of these separate bounded contexts. So in this case, as is illustrated, underwriting has a published language and part of that published language is quote generated. Risk has its own published language, and risk assessed is one part of that published language. And rate has a published language, and one part of or one element of that published language is rate calculated. By having these very well-defined schemas or exchange types that are defined by each context, it makes exchanging information reliable.