Private & Public Microflows

This page details the mechanism for segregating application logic into Private and Public microflows, which is essential for enforcing encapsulation and defining clear boundaries across the application's components. This crucial structural division helps maintain high code quality and effectively manages the flow of control within complex business processes

1. Private microflow

A private microflow is only accessible within its own component or section. It is used to enforce encapsulation and manage the flow of control within a complex business process. Two primary types are distinguished using specific naming conventions:

1.1. Independent private microflows (_ Prefix)

The independent private microflow type is used to hide self-contained implementation details from the outside.

A private microflow must be responsible for it’s own behavior, meaning that it takes full responsibility for validating all of its own inputs (e.g., null checks and simple integrity checks) using pre-conditions to ensure the operation is safe to execute independently.

Private microflows can be tested independently.

1.2. Orchestration dependent microflows (__ Prefix)

This microflow explicitly indicates that it is not responsible for its own pre-condition checks, as these are delegated to the calling microflow. The dependent microflow assumes that its required inputs - such as a unique ID or a calculated value - have already been prepared and are valid.

By definition, such microflows are not independently testable, since they lack the necessary context and preparatory logic provided by the calling microflow. For this reason, implementation of this type of dependency is not recommended.

2. Public microflow

A public microflow serves as the official, reliable interface for its component or section, exposing functionality to other parts of the application.

• Call Rules: Public microflows can be accessed from other components, provided the calling microflow is on the same architectural layer or a higher one, strictly adhering to the Call Hierarchy. This prevents lower-level logic from initiating high-level processes.
• Single Responsibility Principle (SRP): Public microflows must be fully self-contained and robust. They are responsible for validating all preconditions (e.g., security, input data validity) before executing or orchestrating their logic. This guarantees that any external interaction is predictable and safe.
• Encapsulation: These microflows are the only permitted entry points. They ensure that internal, private complexity remains hidden, thereby protecting the integrity of the underlying unit operations.

3. Best practice

It is considered best practice to only call cross component functionality using the public Orchestration microflows located in the Application Logic Level.

This rule ensures that the internal complexity and data integrity of a component remain protected from external modules.

Rule	Why It's Best Practice
Only Call Public ORC_	Enforces SRP (Single Responsibility Principle): The public ORC_ microflow is the component's authorized API. It is responsible for orchestrating the required steps (including internal validation and security checks) for a high-level business process.
Avoid Direct Unit Calls	Prevents Low-Level Coupling: Never directly call another component's public Domain Unit microflows (e.g., OPR_, VAL_). Calling a low-level unit bypasses the target component's necessary business logic and validation rules, risking data integrity.
Stay in the App Layer	Maintains Call Hierarchy: The call must originate from your component's Application Logic Layer. This ensures that cross-component communication occurs at the correct architectural level, which is responsible for coordinating business processes.
Use Dependency Injection	Minimizes Direct Dependencies: When making the call, use Dependency Injection (DI) by passing only the necessary data as parameters. Avoid relying on the calling module to perform lookups or complex data preparation for the target component.