In my previous two articles, I describe lots about Bounded context and context map, where we have learned, How to segregate the domain models using Bounded context? Also learned, How to use context map judiciously to understand the relationship between two contexts, here relationship is a broader statement it does not only represent technical relationship it also defines the relationship between owners of the services, who is in commendable position, who act as downstream etc. Also, we learned different strategy based on the relationships like (Partnership, upstream/downstream,anti-corruption layer etc).
In this article, we will be dealing with a special case when something goes wrong while designing a Microservice. Then how that error bleeds and corrupted other services, Then we will learn how to solve that problem using Interchange context.
Take an Example, In case of our online Student registration module where Registration Module is in commendable position, as it has a partnership relationship with analytics module, Payment module has a downstream relationship with it, Batch scheduler has a downstream relationship with the same. so it is clear Registration module is in commendable position, so the language it published every one has to follow that language, by Registration module API whatever the message it publishes batch, and payment module has to receive the same message , so I can say if the Registration module publish an R language every other module has to consume that R language, So in this system R is the defacto language standard. You can think of this situation on the real-world basis as British people conquered the world in ancient time, so the language they speak i.e English is the defacto language standard for world, A British man and an Indian automatically communicate with English not the reverse even an Indian and a Chinese also talk to each other by English (where no British people are involved).
Now, The problem occurs If the Registration Module has some issues in Design, say Boundary is not properly defined, Message structure not properly designed or Edge cases or Exceptions are not handled properly in that case in spite of a Physical boundary(Bounded context) this problems are bleed into all dependent services, as whole context map is polluted due the error in Registration module. So Registration Module now acting as a Big ball of mud. (BBoM). As per Eric Evans, he called it a Small ball of Mud. So one thing is clear if upstream/commandable system is in danger then the whole Microservice architecture become a mess. As an Architect somehow we have to prevent the bleeding of errors from upstream Microservices/ System to downstream.
If we dig through the DDD patterns we can found ACL is doing the same (Anti-corruption layer) which sits in front of consumer Microservice/System and translate the producer /upstream message structure to Consumer Microservice/System message structure also it handles any kind of errors , So ACL protecting the consumer services from External systems. But think about a system where two services are in a Partnership relationship
they produce and consumes each other messages both dependent on each other and other services dependent on them, in that case rather than putting ACL in front of both Partners we can use a new concept called Interchange Context.
Interchange Context, is such a technique where both partners agreeing upon the model and message structure, so there is one ubiquitous language for both partners, they publish one Message together and other systems consume that message. In this way, two partners can independently change there internal code, internal message structure but in Interchange context, they create a common terminology/Ubiquitous language which understood by this two partners. Every other service, who are dependent on these two partners can consume message from Interchange context.
 |
Conclusion : Interchange context is more robust that Anti-corruption layer, it stops the error to be bled from upstream services , If upstream services has a direct consumers then , upstream service developer should be very careful about the API , any changes in API or errors break others , so Interchange context is kind of centralized facade where partners are created the ubiquitous language and other costumes message from interchange context, partners and dependents services all are free to modify there own data model, message structure but when they communicate to interchange context internal model should converted to Interchange context message structures.
Posts
