Skip to main content

App Layers

The Microflow Typology structure with its immediate interaction rules (the Call Hierarchy) resembles to a ‘Layered Architecture’ or ‘Three-Tier Architecture’ consisting of the following elements:

  • Presentation layer (UI logic)
  • Business layer (application logic)
  • Domain layer (persistence, data access, business rules)

However, it is significant to see that microflow typologies do not completely map to this Layered Architecture. The key difference is scope: typologies define what a specific microflow does and which types it can call, whereas layering defines where logic resides architecturally based on its broader responsibility (e.g., managing UI versus data integrity).

This section with its sub-pages points out the content of the three logic layers and how they are connected to Microflow Typology structure.

1. The three logic layers​

Menditects Testability Framework adopts the horizontal division of a Mendix application as a fundamental architectural principle. It separates the application's logic into three distinct layers: touchpoint, application, and domain.

image-20251124-131032.png

This layered structure helps to manage complexity and enforces a clear separation of concerns by assigning each layer a specific responsibility:

  • Touchpoint Logic: This layer focuses on all user- and API-facing concerns, including data representation, published web services, and user-interface navigation. It is called the Touchpoint logic rather than the Presentation layer because it aligns with Mendix touchpoint microflows and also includes published APIs and scheduled events, which are not strictly presentation logic. (For more details about this layer see the Touchpoint logic page)
  • Application Logic: This layer handles the application's core business functionality. It primarily contains Orchestration microflow typologies, but may also include certain Unit microflow typologies when appropriate. (For more details see the App logic page)
  • Domain Logic: Manages data integrity, validation, and storage of the app. It primarily consists of Unit Microflow Typologies but may also include Orchestration Typologies when needed. (For more details see the Domain storage and logic page)

2. Call hierarchy​

Microflows in a "higher" layer are allowed to call microflows in a "lower" layer. This strict, one-way hierarchy prevents circular dependencies and ensures that each layer remains focused on its specific responsibilities. This rule is partially enforced through microflow typologies - a set of naming conventions that define a microflow's purpose and its place within the call hierarchy. Special attention should be given to Orchestration microflows in the App Logic layer, which should also follow a clear “top-to-bottom” structure, as this is not enforced by the typology schema.

image-20251124-131107.png