Adapter Pattern for Microservices
One of the core principle for Micro services is that they are expected to be decoupled from other domains as much as possible but in real world there are use cases where your service may have to aware of the multiple different domains.
One or more domain services needs to load, update the data from multiple data sources owned by different domains and also need to subscribe to change events whenever there are changes in data sources values.
On top of above, core domain services also need to host the translation logic as different domains are using the different language.
High Level view:
The above mentioned design looks fine in the beginning but it has several challenges:
Service Isolation :
In this case, domain service is not completely isolated from data source services.
If Data source A introduces the changes then changes are required in multiple places:
- Load call to Data Source A Service.
- Data Source A Subscriber
This problem can get more and more complex when more data sources such as Data Source C, Data Source D etc. are introduced and soon your service will end up having tight coupling with multiple other domains. Due to this problem, developers not only have to worry about their domain specific changes but also the changes that happens in other domains such as APIs spec change, Event spec change etc.
One of the reason why teams go for Micro services is because it gives the flexibility to choose frameworks, protocols and language etc but this can become an Anti pattern for your domain service if two or more dependencies are using different solutions:
- Data source A is using Kafka for event publishing while Data source B is using RabbitMQ.
- Data source A is using REST API but Data source B is using GraphQL API.
Domain Language :
In this case, the core domain language is also being polluted with other domain language. This means that developers not only have to learn about their own domain language but also have to understand the domain language of dependencies.
Adapter service pattern can be used to decouple your domain services when it is being overloaded with different set of dependencies from other domains for similar type of information.
This pattern helps in following:
- The core domain services doesn’t have to change when there is any change in Data Source A service, Data Source B service etc.
- The core domain services doesn’t have to host any translation logic. The developers can focus on core concepts.
- The core domain services doesn’t have to worry about the “technology” methods being used by Data Source A service, Data Source Service B etc.
This pattern helps in solving the above mentioned problems but it also require additional service to maintain so this pattern should only be used in situation when the problem space is complex and it’s really worth maintaining an additional “adapter service”.
How to use development patterns with microservices (part 4)
In this 6-part series on microservices application development, we provide a context for defining a cloud-based pilot…