App Logic
Previous steps
To define and start creating the app logic, the implementer must have previously defined the app screens and have a clear understanding of the project's requirements.
Who participates in the app logic creation and maintenance?
The implementer is involved in all the actions performed in this phase.
Where do you work?
To work on your app logic, you must use the processes editor in Studio, and follow the guidelines and best practices outlined in this documentation.
In the Veritran Platform, processes are the central component to define the logic that runs within the app. Through processes, it is possible to model behaviors, validate information, integrate with external systems and transform data. Each process can be invoked from different contexts within the platform: screen components actions, actions in a flow, or calls from other processes.
The building standards and guidelines outlined in this phase will allow you to better understand how logic works, which are the best practices when using logic and which practices should be avoided, thus allowing you to make better decisions and ensure the quality, reusability, and understanding of processes over time.
What You'll Find Here
This documentation provides detailed information, best practices and additional considerations to create logic in a more efficient, clear, and sustainable way. To achieve this, best practices are subdivided and organized into categories for you to follow both in the process creation and maintenance. Within each category you will find:
General definitions and relevant information for each element described.
Best practices to apply when creating, configuring or maintaining each element.
A checklist for you to follow when creating or editing a process.
We suggest you to keep this documentation open while creating or modifying your app's logic, to apply best practices in every step of the way.
There are different types of logic that can be built using processes:
Presentation logic: Controls behaviors within the user interface, focusing on how information is visually displayed and managed. This includes:
Screen components behavior: Changes the behavior of the screen elements as the user interacts with them. For example, showing or hiding elements on screen, enabling or disabling inputs, or dynamically changing texts.
Data manipulation and formatting: Transforms values before displaying them. For example, formatting a number or concatenating texts.
Navigation: Controls the flow between screens or redirects the user based on defined conditions.
Business logic: Focuses on applying specific rules, validations and operations that directly affect the data model. This includes:
Business rules: Validates required conditions, setting restrictions, or making automatic decisions based on specific criteria.
Integration: Enables interaction with external or internal services through the invocation of transactions or call APIs.
The following pillars are defined to serve as a guide to address current challenges and issues, and build processes that are easier to understand, reusable and aligned with best practices:
Clarity and simplicity: Make sure that the logic built is easy to read and understand, both for the implementer and for other team members. This involves properly naming elements, avoiding unnecessarily complex structures and using clear descriptions.
Modularity: Break down logic into subprocesses, reusable structures, and templates to address common problems. This helps save time, reduce errors and ensure consistency across processes with similar goals.
Robustness: Design logic to handle unexpected scenarios, data errors and edge cases. This includes, for example, validating inputs and handling error cases.
Consistency: Apply shared conventions to create more predictable, well-organized and maintainable processes. This applies to structure, naming, formatting and design decisions.
It is also important to establish a set of general principles to guide the logic construction. These principles serve as cross-cutting guidelines that apply regardless of the type of logic or use case, helping ensure clearer, more robust and sustainable solutions over time. These principles include:
Clarity over complexity: Use simple structures and break logic into clear steps to improve understanding and maintainability.
Single responsibility: Each process should handle a single task. When a process tries to solve multiple things at once, it becomes harder to understand and more prone to errors.
Favor reuse over duplication: Whenever possible, reuse existing processes instead of replicating logic in a new process.
Descriptive naming: Use clear and representative names for processes, variables and functions. Good naming reduces the need for additional comments to understand what each part of the logic does.
Self-explanatory logic: Logic should be clear on its own, without needing comments to explain what it does. This is achieved by using meaningful names for processes, variables and functions, simple structures and an organization that supports readability.
Together with the pillars and general principles, best practices serve as mandatory guidelines that enable the development of logic in a more efficient, clear, and sustainable way. Their purpose is to facilitate collaborative work, improve the quality of solutions, and reduce errors and maintenance time.
In these sections, you will find the fundamental aspects to consider when creating or modifying logic. The aim is to provide concrete guidelines that facilitate the development of simple, consistent, and high-quality logic. Best practices can be divided into the following categories:
As there are best practices, there are also implementation approaches that are best avoided. These anti-patterns often hinder process understanding, maintenance or reuse. Below, you will find a list of anti-patterns that are frequently introduced during the building process, for you to identify them in time and choose more suitable alternatives:
Duplicating logic among similar processes.
Leaving disconnected blocks.
Creating extensive processes that are hard to read.
Using confusing or inconsistent naming options. Generic names like process1 or variable1 should be avoided.
Starting the name of a lambda process with the letter L.
Lambda processes templates facilitate the adoption of best practices and promote logic reuse. These templates serve as a starting point for building different types of processes or logic that address common issues, aligned with the guidelines defined in this phase. In addition to saving time, they help maintain consistency across solutions and teams.
Important
Lambda processes templates are still being developed.