Monolith, Not Ball of Mud

See Big Ball of Mud pattern.

My answer for this StackOverflow question, explaining "modular monolith" term introduction redundancy.

All the answers here are good for their attempts to deeply explain things.

What I am not satisfied with is additional complexity with no justifiable value introduced by another new shiny term - "modular monolith" - so lightheartedly. Whereas the most vital task of a good programmer is absolute the opposite - to reduce complexity. For the human cognitive capacity is very limited.

Now. All the solutions required here have been introduced very long ago and used a lot since.

The benefits of knowing & using them are critical for the profession. The solutions have proven their real life applicability for decades.

Learn to combine the concrete flexible implementation out of a number of solutions to adapt to the actual use case. It will be always more flexible than that "modular monolith" can account for. Funny how now it looks more rigid "monolith" that it was just a line ago.

So name those solutions: event bus (pub/sub, observer): 1970s - Smalltalk, 1990s - Gang of Four. SOA (which is service isolation, modularization, in turn is SoC (1970s) and SRP (2000s) in a nutshell) - late 1990s. DDD blue book - 2003. Hexagonal Architecture - 2005.

See how the presence of "modular monolith" is contra-productive. As well as a "monolith" itself is nothing close to being an equivalent to "big ball of mud".

And now how the minimal monolith can be designed:

• isolate subdomains domain logic under the single contact point - Domain Service (s); this is the only point of access to subdomain operations;
• code as many subdomains as the domain requires;
• for synchronous communications call subdomain A domain service from subdomain B domain service;
• for asynchronous communications use event bus(es) (global, local, at will) again from domain services;
• use ports/adapters incoming/outgoing to wrap communications with external (to a subdomain) things (HTTP, DB, email, Kafka, Rabbit etc.);
• deploy as a single unit, isolate teams on subdomains;

This is minimal professionally architected monolith. It is already modular. It does not have to, must not be the "big ball of mud" way in order to be later cured with, the actually redundant, "modular monolith". With the monolith you have just opened doors to modularity, that is essential in every professionally written software.

And lastly, "modular monolith" should assume modules are deployed independently, though it did not sound in answers. With this in mind it becomes just separate isolated services - not that nonexistent "modular monolith" - with their own DBs (where needed). Again they do not need to be "micro" - remember SOA and RPC have been available to software creators for decades.

I do not want to hear things like "SOA is awful" and the like. Professionals make decoupled, extendable, reliable, easily maintainable software with a stick and a rope because they care to know they profession inside out. Instead passers-by make big ball of mud of everything for then posers to "invent" new "shiny" redundant terms like "modular monolith".

To aspiring professionals, as well as to myself, a message - act professionally, do your homeworks monoliths well :)