[CharlieDigital]

I'm sure there are many variants and definitions, but the company I'm at runs one.

The gist of it is that there's one codebase with multiple separate "modules". This codebase is packed and linked as a library and then we build different super slim hosts that load different parts of the monolith in production containers. Usually just different environment variables or config.

But locally, we can run the whole thing in one process. We're.using .NET so `dotnet run` brings up the whole app. Whereas we might run parts of the app in different console hosts in prod, locally they are hosted background services in-process.

From a debug perspective, this is super awesome since you can just launch and trace one codebase. If we broke it out into 3-4 separate services, we'd have to run 3 processes and 3 debuggers. 3 sets of configuration, 3 sets of CI/CD, 3 sets of testing. Terrible for productivity.

We have parts of the system connected to SQS for processing events and if we need more throughout, we simply start more instances of the container all running the same monolith.

I think GCP is probably one of the best platforms for building modular monoliths because of its tight orientation around HTTP push.

[figassis]

I implemented this in one of my past startup jobs. Basically a core banking system that implemented multiple roles of the system, including open banking. Depending on config, it would act as a bank, as an OB service provider, as an OB registry, as a merchant, etc. In addition, it was built in a way that instances, if allowed could talk to each other in 2 ways:

1. As part of the same entity, so you could scale your operation.

2. As part of an ecosystem, so you could for example create an entire open banking network or just a regular network with bank transfers and card payments using proper protocols such as ACH, ISO8583 and ISO2022 for example.

[pshirshov]

We call it "multi-tenant applications" or "role-based applications": https://www.youtube.com/live/Zk0Il6I5MQI?si=BFVL3JkHaj1hcGrZ

And there is a separate concept of a configurable application which can completely reshape its component graph according to some high level configuration flags (like database=prod|dummy), we call it "multi-modal applications".

And we created the perfect tool for wiring them: https://izumi.7mind.io/distage/index.html

[alserio]

I'm looking to break an old java monolith application in something like that: modular code base, single deployment artifact, multiple configurable use cases. I've yet to find a good existing tool to compose the application at build time, other than using a godawful lot of maven profiles combinations

[CharlieDigital]

Hmm; at least in the more recent versions of .NET, Microsoft has really cleaned up the runtime host paradigm so that it's consistent across console (think background services, timer jobs, pull-oriented processing) and web (classic HTTP).

For us, it just becomes a matter of configuring the correct construction of the dependency injection container at host startup using some flag (usually environment variable) to pick the right bits and pieces to load into the container and which services to run from the monolith.

Then each of the host "partitions" gets its own Dockerfile.