Thursday, November 10, 2016

Anti Corruption Layer and Shared Kernel in Domain Driven Design

In today's blog post, I will be discussing few more key terms in Domain Driven Design i.e. Anti Corruption Layer and Shared Kernel. Last week we discussed Ubiquitous Language and Context Maps here.

Anti Corruption Layer

If I am creating a model for a sub-system that communicates with other sub-systems, I might have to interface with other models created by different teams. Since other models are part of different bounded contexts, they might be expressed very differently using their own ubiquitous language. If we use them as is, they might cause corruption in the model in our bounded context.

So in order to avoid this problem, we can have an isolation layer in the middle which takes care of adapting and translating the model from one bounded context to another. This isolation layer is called the anti-corruption layer (ACL).

Anti Corruption Layer in Domain Driven Design

If you have a big, messy and legacy code application to which you need to add more features, usually people think of two options. Either, add to the existing mess which is not a good idea as we are increasing the maintenance nightmare and might introduce bugs in the existing functionality. Or, rewrite the whole application which might not be possible given the time constraints and can also lead to lots of bugs. The third, and most feasible one is to create a new bounded context and anti corruption layer, transform the models you need for your new bounded context and implement the functionality needed. This way your new bounded context is isolated from the existing messy code. This will not only help you avoid creating new bugs in existing application but also will be easier to maintain.

Shared Kernel

If two teams want to collaborate closely and have a lot of cross over in terms of domain logic and concepts, the overhead of translating from one bounded context to another might be too much. So they might decide to share that part of the model, which is known as shared kernel.

Shared kernel introduces risk in terms of one team can break the code of the other team. This also requires the two teams to align their Ubiquitous Languages. It's highly important to have strict coordinating rules around the shared kernel. Any changes to be made to shared kernel should be in consent with the sharing teams. If coordination seems expensive and might not be possible going forward, it might be better to not put anything in shared kernel.


So we saw the importance of anti corruption layer and understood what shared kernel is in Domain Driven Design.


Thursday, November 3, 2016

Ubiquitous Language and Context Maps in Domain Driven Design

In today's blog post, I will be covering a few more key terms in Domain Driven Design. We will be discussing Ubiquitous Language and Context Maps. This is is continuation with last week's blog post about Domain, Sub-Domain and Bounded Context which we discussed here.

Ubiquitous Language

Some people call it the language of the business. Some people call it the language of domain experts. In reality, it is a language shared by the team i.e. domain experts and developers alike. The domain experts do have a high influence on the language but they don't decide everything. It's dependent on how the business thinks and operates. If you have multiple domain experts on the same team, they themselves might have different terminologies. So the domain experts and other team members all need to be on the same page.
Also, there might be scenarios which the domain experts have not even considered. Developers and QAs s are good at finding such scenarios ;) In such cases, the language & terminologies might not even exist and the team might have to come up with some new terms. All these become part of the ubiquitous language.
Lastly, it's not a one-time thing. It grows and changes over time. As the understanding of the domain improves for domain experts and other team members, new terms are added and existing terms are updated with time.

Ubiquitous Language and Context Maps in DDD

Context Maps

A context map can capture the technical and organizational relationships between various bounded contexts. It shows the boundaries of the bounded contexts and the contact points of these contexts among each other.
Also, it shows how various bounded contexts communicate with each other and what type of relationships exist among them. It represents the holistic view of the application. This is helpful in informing the teams their own communication points and how they can communicate with other teams.
A context map need to be updated whenever there is any change in the boundaries of the bounded contexts or change in how they talk to each other.


So we defined some more key terms in the Domain Driven Design this week. We will be continuing with our journey by learning more about context maps and what it contains next week.

i)  Domain Driven Design By Eric Evans;
ii) Patterns Principles and Practices of Domain Driven Design By Scott Millet