Clear boundaries and contracts are just a side effect of working in a service architecture, I've found. If this is your reason for doing it - just define a styl

Clear boundaries and contracts are just a side effect of working in a service architecture, I've found. If this is your reason for doing it - just define a style guide on how to isolate code and make sure people (or procedures) keep it. But there are many other valid reasons for services - different deployment cycles, better resource utilization, faster and safe deploys, etc. It's just about using the right tool and thinking about implications. I don't know if such a framework exists, but I really want a system that abstracts this to a certain degree - while the contracts between parts of the system are defined, whether any module works as a service with its own deployment policy over network or as part of a monolith is not expressed in application code but as a configuration, and code generation handles the underlying logic. So you can write your app as a modular monolith, but when you think that for operational reasons there is a reason to spin off some part of it as a service, you reconfigure your build rules instead of your code.