Modular monoliths FTW verses upfront microservices
This article discusses the differences and similarities between Modular Monolith and Upfront microservices for microservice architecture.
Identifying (micro)service boundaries is a challenge and becomes relatively easy as we learn more about the business domain. So we wanted to try a modular monolith (modules within microservice) approach.
As the module matures and we see it becoming first class microservice, we can take it out of the modular monolith very easily and with less efforts as module is developed as first class concept with loose coupling with other modules.
This worked quite well in spring webflux + kotlin microservices as well as Scala Play microservices.
With modular monoliths it is easy and cheaper to add, remove modules. This helps greatly to come up with correct boundaries for (micro) services as we go along delivering project.
You can apply Domain Driven Design patterns (tactical patterns) within each module. Each module can be thought as a bounded context in Domain Driven Design terms.
Each module should have its own db migrations. And modules should not access other modules database tables directly.
One module should access other modules through controllers only (making in process call instead of http call). Keeping interaction at controller level avoids one module depending on the domain layer of another module as Controller would return view models.
When we take out module and make it microservice we will move in process api calls from one module to other to http calls and move database tables for that module to new microservice. Note each module has its own set of database tables when module is first created.
We wanted to choose an approach so that we can have different modules/services in one place but not as a one monolith service and we can easily extract them out if needed.
Tips for making it successful
Each module has its own Domain classes as well controller, application services, repositories/daos.
You can apply Domain Driven Design pattens in each module.
Each module has its own DB or DB Schema. And DB Migrations.
Modules talk to each other via published APIs
One module is not allowed to access DB of other module.
One module can not access other modules classes directly unless they are published as API to be used.
If you please like this blog, please clap and/or leave response below.
