Modular Monolith vs Upfront Microservices
This article discusses the differences and similarities between Modular Monolith and Upfront microservices for microservice architecture.
Join the DZone community and get the full member experience.Join For Free
Finding (micro)service boundaries is a challenge and become relatively easy as we learn more about the business domain. So, we wanted to try a modular monolith (modules within the microservice) approach.
As the module matures and we see it becoming the first-class microservice, we can take it out of the modular monolith very easily and with fewer efforts as the module is developed as a first-class concept with loose coupling with other modules.
This worked quite well in spring webflux and kotlin microservices as well as Scala Play microservices.
With modular monoliths, it is easier and cheaper to add and remove modules. This helps greatly to come up with correct boundaries for microservices as we go along delivering projects.
You can apply Domain Driven Design patterns (tactical patterns) within each module. Each module can be thought of 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 the controller level avoids one module depending on the domain layer of another module as Controller would return view models.
When we take out the module and make it a microservice, we will move in process API calls from one module to another and then to HTTP calls to move database tables for that module to the new microservice. Note that each module has its own set of database tables when the module is first created. We wanted to choose an approach so that we can have different modules or services in one place but not as a one monolith service, and so that we can easily extract them out if needed.
Tips for success:
- Each module has its own Domain classes as well as controllers, application services, repositories/daos.
- You can apply Domain Driven Design patterns in each module.
- Each module has its own DB or DB Schema And DB Migrations.
- One module is not allowed to access the DB of other modules.
- One module can not access other modules' classes directly unless they are published as API to be used.
Thanks for reading. Please leave your comment or like this article if you found it useful!
Published at DZone with permission of Sandeep Jagtap. See the original article here.
Opinions expressed by DZone contributors are their own.