Brainstorming about moving from monolith to microservice
I will talk about modularization of software architecture.Let’s depict fictional scenario of work place.We are working on small Erp project that is based on monolith architecture and again having some modules like Sales,Stock,Finance,Human Resource..etc.In the beginning our customers were consisting of some domestic companies and our development team size was approximately 10.
But afterwards our customer size have begun to expand.So also we have decided to sell our Erp project to abroad and to expand our team size.
So for now the work have begun to become complex.We also want us to manage team seamlessly.Architecture as per needs and team size in the beginning were small monolith.But in new situation team size and needs are much bigger than first monolith.We want to assign each subdomain(Sales,Stock,Finance,Human Resource) to seperated team that is cross functional [5]
We may choose to architect our software as per Domain Driven Design and also modularization.I think in terms of modularization it is not important whether it is modular monolith or microservice.
“A modular monolith is a software design approach in which a monolith is designed with an emphasis on interchangeable (and potentially reusable) modules” [1]
“Microservices — also known as the microservice architecture — is an architectural style that structures an application as a collection of services that are
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organized around business capabilities
- Owned by a small team” [2]
We can use modular monolith architecture(see also [3] in references) to convert our monolith to microservice as per DDD or we can use only modular monolith architecture if we don’t have enough devops team.Because microservice architecture devops maintaince is harder than modular monolith.
Let’s return our Erp project.First monolith architecture would be most probably as the below picture
As you see,Our app first version has been designed as per Tactical-Domain Driven Design. [4]
I mean our subdomains(Sales,Stock,Finance,Human Resource) are scattered from application services to repositories.But in this architecture we are losing seperated subdomain as per seperation of concerns.Because Sales application services will easily use stock application services and the other components as part of Tactical Domain like repositories too.Human Resource subdomain repositories can use Stock Repositories.There will be a lot of inter dependencies between subdomains.It is very hard to extract here micro services.
But we can firstly to implement modular monolith like the below picture to go to microservice.
In this architecture we seperated each subdomains as seperated application.As per the needs, we can choose communicaton styles like async via message broker and sync via rest api.
For example if a sale occurs in Sales application,It will send Sales Event to message broker,then stock application consume this Sales Event and it will decrease stock size.Or sometimes we can need sync so maybe before sales we want to check balance amount of the customer.If it is suitable,we allow the sale.Sales application can call Finance balance amount endpoint via rest api.As per the result,It can perform Sale then send the event to message broker and again finally Stock application can consume this Sale Event.
There are a lot of combinations in terms of application communication.The thing is that we are in large application and large team size.So using modular monolith we have two advantages.First our each application in big monolith will be in one cross functional team’s responsibility.Second each application size will be smaller than the first version of monolith.None of them will not affect in terms of deployment,development or minimally.
Micro services or modular monolith’s application must be highly cohesive and loosely coupling.I mean we must seperate our monolith application via true seperation.For example if A subdomain business is closely related with B subdomain,It is unnecessary to make them seperated application as A and B.Because we can not provide high cohesion.if A and B needs cohesion,we must not seperate them.They must be as AB application.For loosely coupling when we seperate an application as x application and y application.They must not need each other directly.X application can work independently and also y application too.
As a result,I think it will be better to use modular monolith for moving to microservice.But you can choose to stay in modular monolith.Important one is to seperate subdomains well.You should choose whichever is best suit for you.Thank you.
References
3. https://github.com/kgrzybek/modular-monolith-with-ddd
4. https://vaadin.com/learn/tutorials/ddd/tactical_domain_driven_design
5. https://fatihkosal.medium.com/domain-driven-design-and-scrum-abd0bbabbe09
