This is just DDD with a microservice lens, though the interaction between webapps part is a bit too simplistic here. Each domain context should have it's own d

This is just DDD with a microservice lens, though the interaction between webapps part is a bit too simplistic here. Each domain context should have it's own datastore and that datastore shouldn't be touched outside the domain, instead contracts (either http calls, rpc, rabbit message, what have you) should be used to disseminate data into other domains readviews. In regards to how SCS suggests managing Front Ends (FEs), this is going to be a very subpar experience for users without proxy layers and even then can result in inconsistent page-to-page experience. For this reason, divorcing the web layer and treating it like another API consumer akin to a mobile app makes life much easier. Web apps can be hosted statically and robustly, and then your worker/api/data domains can be scaled/shuffled as need be. There are some good reasons to generally restrict your code to a subset of well defined languages and technologies because one of the benefits of small composable architectures like this is ownership being dynamic. One team can easily jump from one domain to the next as they tackle user features, which usually exist across domains. The other issue is that each domain needs to be kept updated for security, and more languages/libraries/technologies makes that problem more difficult over time. Having a very consistent stack allows upgrades to be quick, handled by anyone available, and lets teams focus on user problems instead of arguing about tech choices. There are issues with disseminating data across various datastores, mostly tied to maintaining data retention and deleting data when needed as well as PII behavior. In many cases this is more or less solved by just restricting PII to a single domain but there are cases such as adtech where all domains are basically going to touch PII. As with any system with readstores, your team needs to have good practices and handling with api contracts, consistency problems and handling Source-of-Truth correctly