The ambiguity level and the number of unknowns are definitely a crucial factor when it comes defining our modules, and especially when it comes to the implementation strategy choice

The more ambiguity we have, the more fluid and dynamic our domain is and the less certainty about its final shape we have, the more we should focus on adopting a strategy where it is the least costly to completely redesign and rearrange our modules.

Simple modular monolith: folders. Microservices needs one application per module. That's a high cost.

requirements, and some of them might have needs somewhere in between. Thanks to the fact that every module is now basically a separate application, we can assign different resources to each module and have it in a different, often dynamic, number of replicas, based on its own unique needs.

We can eliminate many problems of microservices by adhering to one, simple rule:

When serving any external network request, synchronous or asynchronous, a service can not make any network calls to other services, synchronous or asynchronous.

About SPAs: avoid global things that apply everyhwere

As the last resort, we can have a separate SPA per a few selected routes, having as many html pages as we have SPAs (multiple SPAs approach), or use the Micro Frontends

To reiterate, we went through the following strategies, ordered from simplest to the most complex one:

• Simple Modular Monolith
• Modular Monolith with Isolated and Independently Deployable Modules
• Modular Monolith with Helper Services
• Constrained Microservices - Microliths
• Microservices

I would say things are always easy when the modules are clear, defined and documented :)