> I really don't understand, why tying your business logic and domain to any particular framework is considered acceptable.

I am all for keeping business logic separate from technology/framework. To be honest, I have not worked on a project that followed it. And in all my production projects that lasted multi-years, the biggest challenge was to avoid the "big ball of mud" issue. Framework code splattered all over was never a problem as we never had to replace the framework. So in practice how important is it?

> Business can have more than one domain, and this is where the use of microservices actually makes sense.

I think we are in agreement in general, but not aligned on the terminologies. What you call domain, I am referring to as subdomain. Eric Evans in his book uses both "core domain" and "core subdomain" interchangeably which might explain the confusion. The other types "Generic" and "Supporting" also refer to subdomains. Vaughn Vernon in his book maps Bounded Contexts to subdomains (not always 1:1) which eventually map to Microservices. And that's how it is used in most of the text out there. Using a different interpretation adds confusion and makes discussions harder. And yes a business can have more than one domain - e.g. Google does Search and Android (amongst others).

In my blog, I use transaction across both subdomains to highlight the strong consistency and talk about it under Limitations section. In the next blog I will show how it can be resolved to eventual consistency with events.