> For the complete documentation index, see [llms.txt](https://kdongs.gitbook.io/kdocs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kdongs.gitbook.io/kdocs/monoliths/monoliths.md).

# Monoliths

## About

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

{% hint style="info" %}
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.*
{% endhint %}

{% hint style="success" %}
***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.
{% endhint %}

{% hint style="danger" %}
***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.
{% endhint %}

### 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.

{% hint style="info" %}
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.*
{% endhint %}

{% hint style="info" %}
A good solution is to [Broken mention](broken://pages/ZS5a7MR1C5UQDNaJOvNl) the Domain.
{% endhint %}

#### Modular

<figure><img src="https://4200834936-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FyD2XD9rgSbhWGKntQfv6%2Fuploads%2FoqViGkto4Fdopjbeihhh%2Fimage.png?alt=media&amp;token=1b8b906d-b366-4d29-8e18-b99ee629250f" alt=""><figcaption></figcaption></figure>

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`.

{% hint style="info" %}
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.
{% endhint %}

<img src="https://4200834936-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FyD2XD9rgSbhWGKntQfv6%2Fuploads%2FR9B8H6ohMbJYQNsaDTkv%2Ffile.excalidraw.svg?alt=media&amp;token=23796e71-ac44-4d33-9aff-98f42006fbcc" alt="" class="gitbook-drawing">

{% hint style="info" %}
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.*
{% endhint %}

{% hint style="success" %}
Allows you to have specialized teams by module.
{% endhint %}

{% hint style="warning" %}
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.
{% endhint %}

Example of a Project:

<img src="https://4200834936-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FyD2XD9rgSbhWGKntQfv6%2Fuploads%2F150lOZiNrsGqDrMgf2eN%2Ffile.excalidraw.svg?alt=media&amp;token=3973f170-374a-4a23-9f65-5280261168cd" alt="https://github.com/devfullcycle/fc-monolito" class="gitbook-drawing">

#### Modular with a segregated Database

<figure><img src="https://4200834936-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FyD2XD9rgSbhWGKntQfv6%2Fuploads%2FTGyPgNJYofnvoA6lsiGc%2FScreenshot_6.png?alt=media&amp;token=88d56822-206e-427e-a1ed-a6b51c2f0285" alt=""><figcaption></figcaption></figure>

Each module may have its own database.

{% hint style="warning" %}
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.
{% endhint %}

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)*