Abstract
In this post, I will be discussing the Command Pattern in the context of Microservice Architecture.
Should not be taken as CQRS which is far different from the Command Pattern used in object-oriented programming.
This post will be helpful to those who are interested in learning about design patterns, software engineering and particularly microservice architecture.
Introduction
We have a lot of departments which make a lot of services. In one flow, we add and remove from sales orders and generate a lot of versions for consumption. The sales order services are tightly coupled with other departments making it hard to extend and manage… The command pattern to rescue.
Advantages
The invoker and receiver do not need to know about each other as well as other receivers can be added easily to reach an expected state. All services talking to command manager would have a clear flow.
They only would send the command to ADD or REMOVE, flight or hotel and/or ancillaries, and.. would not want to know what are the underlying schemas or whatever to communicate with each other ?
I am feeling the advantages already…
Problem in hand
Services tightly coupled in a service oriented architecture (microservice) while using the event driven sourcing.
- Extra consumption of resources
- Extension to other services (conform to other schemas)
- Domains getting polluted with each other’s jargons
- They will be added to each other’s bounded context
- Now this is getting to my guess would be, a big ball of mud ? back to monoliths.
- Leave your comments, I would be happy to know.
After the switch
The command pattern by default exclusively gives a roll-back functionality, diagnosis phases, and what not ?
Suppose, a customer wants to have his or her flight changed to a specific date, the invoker would send a command saying a remove to a flight then if they have accommodation that would need to be moved as well, so some combination of commands would be sent to understand if they all go together or not because.. Think of it this way, a hotel might not be available on those dates where the flight needs to be moved to or. That would be a diagnosis phase and customer would be informed accordingly.
There are endless possibilities.
So, no more extensive use of events driving to each way. Clear sight of what is needed and how it can be achieved.
Give a command to invoker, invoker makes sure that is achievable by calling each department (issues a matching sequence of commands) and if the desired state is possible, announce it to the stakeholder. An extra and neat line of encapsulation.
Let me know if you have liked this post and would like to know anything else about this topic.
Thanks for visiting!