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.


No comments:

Post a Comment