I am designing a new application in Mendix using "API first" mantra. The application also has UI. I need to architect the solution in such a way that the Web Services and user interface execute identical business processes.
The way I architect the application is by having three modules. The first module contains entities and microflows to execute business logic. This module is forbidden to have any UI. Then I have one module for user interface, and one module for Web Services. These two modules are forbidden to have any business logic. For example, a microflow behind a page would contain only one node calling a business logic microflow from the first module. Very much the same is happening with the Web Services module. I think this module design guarantees that the same business logic is called by both pages and Web Services.
Did anybody have similar requirements? How did you address those?
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?
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?