You don't have to separate the logic like that with modules. Just use folders to separate the business logic pieces from the UI pieces. The integrations should definitely be in one or more modules as a best practice. Generally, I build apps to have a module for Master Data and the logic associated as well as new/edit pages if the system of record, and transaction modules based on high-level workflow, where the folders capture the process steps. For example, if building a Product Order app, the products would be in master data module and the orders would be in the transaction module. The UI would be in each as needed. I get what you are trying to do, but I think your abstraction isn't necessary or giving you a benefit. If you want to build it as a microservice architecture, then create API's for each of the transaction step flows and expose them, but be wary as well with what that brings. Hope that helps?
Rene, thank you for the reply. The way I read it now is that I will create two modules: one containing the business logic with UI and the other dedicated to REST API channel. In the business logic module I will create private and public microflows. UI and REST API are allowed to call only public microflows. This way I put into the application architecture the requirement for the identical behavior of the UI and REST API.
Nolan, that is another Pandora box I need to open and close. What is the difference between yet another module for an application and a different Mendix application. In your example, should master data become yet another module in the eCommerce application, or should I build it as a separate Mendix application. What is the line which makes me go one direction or the other?