On an idea level, i'm all for DDD (domain driven design) and many of the ways to achieve modularity - be it at code level, like in the new versions of Java, be it on a library level, with shared common code, or maybe even having a hexagonal architecture, or microservices.

That said, in reality, doesn't any sort of modularity imply increased complexity?

  - you need to manage your modules and figure out where to put the code
  - you need to figure out mechanisms to share and reuse it, as well as test every single integration (breaking changes will be harder)
  - you need to invest significant resources into the Ops side of things - maintaining multiple deployments and making them talk to one another

It seems like it would lead to trading one set of constraints for another, each having their downsides. In my subjective opinion, monoliths are the only way to go for small teams (~1 pizza) and relatively small systems (~10k MAU), maybe migrating over to modular monoliths as time goes on, and only then branching out to other approaches.

I actually wrote a blog post on modular monoliths a while ago, that mentions using feature flags, however i'm not sure whether the tone/quality is entirely appropriate for HN: https://blog.kronis.dev/articles/modulith-because-we-need-to...

Regardless, it feels like the industry perhaps jumped over the concept of modular monoliths entirely and went straight for microservices.

Of course, if we're talking about modularity purely on the code level, then dynamic loading of code is its own can of worms, as can also be many methods of installing extensions.