This chapter is about vast projects which require the consolidated endeavors of several teams and issues faced when several teams works on small modules of a code. It brings about change of the model, and it is possible that this change will break application functionality.
This problem can be approached by not attempting to keep one big model that will break apart later, we ought to intentionally isolate it into a few models
Set of techniques used to maintain Model Integrity
The Ubiquitous Language ought to be the main language used to express a model.
Each model has a context which is implicit. When working on huge application need to make different contexts for different models. The main step is to define context of each model. A Bounded Context (not a module) provides the logical edge inside of which the model develops. Need to define boundaries and relationship between different models.
The bigger the team, the bigger the possibility of model to fragment. Nonetheless, breaking down the system into ever-smaller contexts in the long run loses an important level of integration and coherency. We require a procedure of integration to ensure that all the new components which are included fits perfectly into the rest of the model, and are implemented effectively in the code. We need a procedure used to merge the code.
An enterprise application has multiple models, and each model has its own particular Bounded Context. It is advisable to utilize the context as the basis for team organization. While each team works on its own model, it is useful for everybody to have an idea of the general picture. A Context Map is an archive which outlines the different Bounded Contexts and the relationships between them. It can be a diagram, or it can be a written report. Everybody should know the boundaries of each context and the mapping amongst contexts and code.
Common practice is to define a context, create modules for each context and use a naming convention to indicate context each module belongs to.
The purpose for the Shared Kernel is to decrease duplication, yet at the same time keep two separate contexts. Both teams may modify the portion of a code, and they need to integrate the changes. A test suite ought to be set up, so every change done to the piece to be tried right away.
Sooner or later, for reasons unknown, we might decide that different contexts should share a subset of the model implementation. This implies they might share code, data representation (entities) and data storage. This gives us the benefit of allowing us to not require any translation layers or anti-corruption layers
There are times when two subsystems have a special relationship: one depends a great deal on the other. Context is different however the processing result of one system is fed into another. They do not have a shared kernel, may not be conceptually correct or technically not possible.
There is a tight relation between these two modules. The client module relies on upon the supplier module. This implies the supplier can not change openly, as these progressions could break the client. The teams responsible for these modules must work intently to coordinate the evolution of these modules.
When we have a client/supplier relation be that as it may, for reasons unknown, we don't have the essential coordination and motivation of the supplier to coordinate with the client team, the client team is all alone when dealing with the supplier evolution.
The client team has couple of options. The most obvious one is to isolate from the supplier and to be totally all alone.
We can chose from the above options,
We often encounter circumstances when we make an application which needs to interact with legacy software or a separate application. There are different ways for our client framework to interact with an external one. One is via network connections. Another technique for interaction is the database. An ANTICORRUPTION LAYER is a method for linking two BOUNDED CONTEXTS. The motivation behind why you might utilize an anti corruption layer is to create a little padding between subsystems with the goal that they don't spill into each other.
See the layer as a Service from the client model.
We should only integrate sub-systems if we really, REALLY, need to. We should, as much as possible, define bounded contexts that are completely independent, completely disconnected from other bounded contexts, and therefore have no need for integration.
When we try to integrate two subsystems, we usually create a translation layer between them. This layer acts as a buffer between the client subsystem and the external subsystem.
If a bounded context connects to many other bounded contexts, we will be putting a lot of effort on building translators. Solution is to see the external subsystem as a provider of services. If we can wrap a set of Services around it, then all the other subsystems will access these Services, and we won’t need any translation layer.
To prevent such issues, we can simply create a coherent and clean API in our Bounded Context, supported on a set of Services that provide the functionality needed by the other Bounded Contexts.
A large domain has a large model even after we have refined it and created many abstractions. It can remain big even after many refactorings. In situations like this, it may be time for a distillation. The idea is to define a Core Domain which represents the essence of the domain. The byproducts of the distillation process will be Generic Subdomains which will comprise the other parts of the domain.
Data must flow through the above Services, in some language they can all understand. This language is a textual representation of the data, its a Data Interchange Language. XML or JSON