Monolith, Not Ball of Mud

 |  Niceties

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 use 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 them as life to adapt for life that is 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 does not have to, must not be the "big ball of mud" way. Just for not making it so, you open 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 all professionals 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, posers "invent" shiny terms. To aspiring professionals, as well as to myself, a message - act professionally, do your homeworks monoliths well :)