This article discusses the differences and similarities between Modular Monolith and Upfront microservices for microservice architecture.

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.

#microservice architecture #software engineering #modular monolith #microservices