Monoliths

About

A software design choice where all components of an application are built into a single unit. (All-in-one)

A monolithic system is a SINGLE Unit of Deployment.

Ex.: If you make a change in a Support module of your application, and to re-deploy it, the other modules like Financial modules also gets re-deployed.

Advantages:

Codebase: All components of the application are built into a single codebase.

Development: It's easier to develop and deploy because everuthing is in one place.

Drawbacks:

Scalability: Scaling the entire application is required, even if only some parts need it.

Reliability: A bug in any part of the application can affect the entire system.

Update: Updating the application is time-consuming because the entire code base need to be updated.

Flexibility: More difficult to adopt new technology since the entire application needs to be changed.

When to use it

In new projects

Where the business domain is not clear enought or have too many instabilities/changes.

Avoids complexity in deployment.

Types

Single Process

These are the default (Unit of Deployment) applications.

Single process monotliths can be divided in three types:

High Coupling

There is no context. There is no segmentation, everything is coupled to everything.

There can be undesired side effects.

This can become quite caotic.

Ex.: A User is only one Entity for the entire application, independent of which context they should belong to, because there are no contexts delimited.

A good solution is to the Domain.

Modular

Where each context (bounded context) can become a isolated module in the application. And these modules access the same database.

This reduces the coupling between contexts.

And the modules can communicate with contracts/interfaces and facades.

So instead of modules calling each other directly, they will use an abstract interface to do so.

External interfaces will still call the modules directly.

Entities can be duplicated, having only their context necessary attributes.

Ex.: You can have multiple types of User for different contexts, and they will only have attributes that are necessary for their contexts, but they will share the same ID. This way they can even communicate between them.

Allows you to have specialized teams by module.

When working with modules, it is possible to have a Shared Kernel, which is a shared peace of code or library between modules.

Changes to this shared kernel can lead to breaks on multiple modules.

It must be clear who is responsible for updates on it.

Example of a Project:

https://github.com/devfullcycle/fc-monolito

Modular with a segregated Database

Each module may have its own database.

Data may get duplicated.

Ex.: You User table may be in two or more databases, and you will have to maintain integrity on them.

But you could hold shared data in a single DB, and have each specialized context data in separated DBs.

Even though this seams familiar with Microservices, we still have:

• Single Deploys. (Single Unit of Deployment)

• Simplified Observability.

• These modules communicate internally between them.

• There is still only one language.

Distributed Monoliths

Black Box

These would be closed code software. (Private softwares, which we don't have access)