Modular Monolith

In the ever-evolving software development landscape, choosing the right architecture is like laying the foundation for a building. The architecture dictates how the software is structured, impacting its scalability, maintainability, and overall success. Traditional monolithic architecture and microservices have long been the dominant paradigms, each with advantages and challenges.

However, a new architectural style has been gaining traction—Modular Monoliths. This approach aims to offer the best of both worlds by combining the simplicity of monoliths with the flexibility of microservices. It serves as a middle ground that addresses some of the complexities associated with microservices, making it particularly appealing for small to medium-sized projects or teams transitioning from a traditional monolithic architecture.

I wrote an article about this in 2017 entitled Microservices Aggregation, but nowadays, the name Modular Monolith is gaining...

What is a Modular Monolith?

A Modular Monolith is an architectural style that aims to combine the best aspects of traditional monolithic architectures and microservices. It organizes the software application into well-defined, loosely coupled modules. Each module is responsible for a specific business capability. However, unlike microservices, all these modules are deployed as a single unit like a monolith.

The core principles of a Modular Monolith are:

• Treat each module as a microservice
• Deploy the application as a single unit

Here are the fundamental principles of a successful microservice as studied in Chapter 19, Introduction to Microservices Architecture:

• Each microservice should be a cohesive unit of business
• Each microservice should own its data
• Each microservice should be independent of the others

In a nutshell, we get the best of both worlds. Yet, understanding how a Modular Monolith compares with the microservices...

Implementing a Modular Monolith

Planning is essential before building a Modular Monolith. We must consider what each module does and how modules work together. A good plan helps us avoid problems later on.

Choosing the right tools to create a lean stack is also essential. The good news is that we don’t need to define a large shared stack since each module is independent. Like a slice in Vertical Slice Architecture, each module can determine its patterns and data sources. Yet, we must define a few common elements to assemble a Modular Monolith successfully. Here are a few items to consider to improve the chances of success of a Modular Monolith:

• The modules share the URL space
• The modules share the configuration infrastructure
• The modules share a single dependency injection object graph (one container)
• The modules share the inter-module communication infrastructure (event broker)

We can address the first two elements using the module...

Project – Modular Monolith

This project has the same building block as Chapter 18 and Chapter 19, but we use the Modular Monolith approach. On top of the previous versions, we leverage events to enable the shopping basket to validate the existence of a product before allowing customers to add it to their shopping basket.

The complete source code is available on GitHub: https://adpg.link/gyds.

The test projects in the solution are empty. They only exist for the organizational aspect of the solution. As an exercise, you can migrate the tests from Chapter 18 and adapt them to this new architectural style.

Let’s start with the communication piece.

Sending events from the catalog module

For the catalog to communicate the events that the basket module needs, it must define the following new operations:

• Create products
• Delete products

Here are the API contracts we must create in the Products.Contracts project to support...

Transitioning to microservices

You don’t have to transition your monolith to microservices; deploying a monolith is fine if it fits your needs. However, if ever you need to, you could shield your aggregator with a gateway or a reverse proxy so you can extract modules into their own microservices and reroute the requests without impacting the clients. This would also allow you to gradually transfer the traffic to the new service while keeping the monolith intact in case of an unexpected failure.

In a Modular Monolith, the aggregator registers most dependencies, so when migrating, you must also migrate this shared setup. One way to not duplicate code would be to create and reference a shared assembly containing those registrations. This makes it easier to manage the dependencies and shared configurations, but it is also coupling between the microservices and the aggregator. Leveraging the code of this shared assembly is even easier when the microservices are part of the same...

Challenges and pitfalls

It is a misconception that monoliths are only suitable for small projects or small teams. A well-built monolith can go a long way, which is what a modular structure and a good analysis bring. Modular Monoliths can be very powerful and work well for different sizes of projects.

It is essential to consider the pros and cons of each approach when selecting the application pattern for a project. Maybe a cloud-native, serverless, microservices application is what your next project needs, but perhaps a well-designed Modular Monolith would achieve the same performance at a tremendously lower cost. As a rule of thumb, start with the simplest approach.

To help you decide if a Modular Monolith is the way to go, here are some potential challenges and how to avoid or mitigate them:

Challenges and pitfalls	Mitigating actions
Too much...

Summary

In this chapter, we learned about the Modular Monolith architectural style, which blends the simplicity of monolithic architectures with the flexibility of microservices. This architectural style organizes software applications into distinct, loosely coupled modules, each responsible for a specific business capability. Unlike microservices, we deploy these modules as a single unit, like a monolith.

We discussed the benefits of Modular Monoliths, including easier overall management, development, and testing experiences, as well as improved cost-effectiveness and a simplified deployment model.

We saw that a Modular Monolith comprises modules, a module aggregator, and an inter-module communication infrastructure—event-driven in this case.

We learned that analyzing the domain, designing the modules, and identifying the interactions between modules before starting the development improves the chances of success of the product.

We touched on transitioning...

Questions

Let’s take a look at a few practice questions:

1. What are the core principles of a Modular Monolith?
2. What are the advantages of Modular Monoliths?
3. What are traditional Monoliths?
4. Are poorly defined module boundaries beneficial to a Modular Monolith?
5. Is it true that transitioning an application to microservices architecture can be a significant undertaking?

Further reading

Here is a link to build upon what we learned in the chapter:

• Microservices Aggregation (Modular Monolith): https://adpg.link/zznM
• When (modular) monolith is the better way to build software: https://adpg.link/KBGB
• Source code: https://adpg.link/gyds

Answers

1. We must treat each module as a microservice and deploy the application as a single unit—a monolith.
2. A few moving parts make the application simpler. Each module is independent, making modules loosely coupled. Its simple deployment model leads to ease of deployment.
3. Traditional monolithic architectures built the application as a single, indivisible unit, often resulting in tightly coupled functionalities. These were usually built using layers.
4. False. Poorly defined module boundaries hinder the health of the application.
5. True. Even if a well-conceived Modular Monolith can help, the transition will be a journey.

An end is simply a new beginning

This may be the end of the book, but it is also the continuation of your journey into software architecture and design. I hope you found this to be a refreshing view of design patterns and how to design SOLID apps.

Depending on your goals and current situation, you may want to explore one or more application-scale design patterns in more depth, start your next personal project, start a business, apply for a new job, or all of those. No matter your goals, keep in mind that designing software is technical but also an art. There is rarely one way to implement a feature but multiple acceptable ways. Every decision has trade-offs, and experience is your best friend, so keep programming, learn from your mistakes, become better, and continue. The path to mastery is a continuous learning loop. Remember that we are all born knowing next to nothing, so not knowing something is expected; we need to learn. Please ask questions, read, experiment, learn, and...