ODC Architecture Specialist key terms

OutSystems Developer Cloud is a managed, cloud-native platform for building, deploying, and operating applications. It provides separate development and runtime stages, automated infrastructure, and integrated security and monitoring services.

An isolated logical container in ODC for a single organization. It holds that organization's applications, users, data, configurations, and security settings, keeping them separate from other customers' resources.

A distinct environment in an ODC deployment pipeline, such as Development, Test, or Production. Applications are promoted between stages after validation, and each stage has its own runtime and configuration.

A design model that organizes an application into layers, typically end-user, core, and foundation, and shows how modules depend on one another. It helps architects review coupling and reuse before implementation.

A design principle where modules interact through stable, minimal interfaces instead of relying on each other's internal details. It reduces the blast radius of changes and makes independent deployment easier.

The degree to which the elements inside a module belong together and serve one clear purpose. High cohesion makes modules easier to understand, test, reuse, and change without unintended side effects.

An ODC container for related modules that together deliver a business capability. It is the unit that teams version, deploy, and manage through the platform's lifecycle stages.

A building block in ODC that contains UI, logic, data, or integration elements. Modules can be web apps, mobile apps, libraries, or services, and they expose elements for other modules to consume.

A reusable ODC module that provides actions, entities, or UI patterns to other modules but is not deployed as a standalone application. Libraries centralize shared logic and reduce duplication across apps.

An ODC module type for responsive browser-based applications. It runs client-side logic in the user's browser while using server actions and data entities for business logic and persistence.

An ODC module type that delivers a native mobile experience, including screens, navigation, and device capabilities. It can use client actions for local interaction and server actions for secure business logic.

Logic that executes on the ODC server rather than in the user's device or browser. It is used for data access, integrations, and business rules that must remain secure and consistent across clients.

Logic that runs in the user's browser or mobile device. It handles UI behavior, navigation, and lightweight validation, while sensitive or data-heavy work should be delegated to server actions.

A reference from one module to an element exposed by another module. Dependencies must be resolved when the application is compiled and deployed, and they shape the impact of changes.

An action exposed by an ODC module so that other modules or external systems can call it remotely. Service actions commonly back REST or SOAP integrations and enforce input validation and permissions.

A data model element that maps to a database table in ODC. Entities define attributes, relationships, indexes, and validation rules, and they are accessed through aggregates, SQL, or server actions.

An entity whose records are defined at design time and deployed with the application. It is useful for reference data such as statuses, categories, or configuration values that change infrequently.

A visual query in ODC that reads, filters, sorts, and groups entity data. Aggregates are optimized by the platform and are preferred over hand-written SQL for most data retrieval needs.

A custom SQL statement embedded in an ODC module for data operations that aggregates cannot express efficiently. It should be used carefully because it can bypass some platform optimizations and portability guarantees.

A defined association between two entities, such as one-to-many or many-to-many. It enforces referential integrity and lets developers navigate related records in aggregates and logic.

A database structure that speeds up lookups, filtering, and sorting on entity attributes. Indexes can also enforce uniqueness, but unnecessary indexes add write overhead and should be reviewed.

A named permission set in ODC that is assigned to users. Roles control access to screens, actions, entities, and APIs, and they form the basis of application-level authorization.

An authentication pattern where a user logs in once through a central identity provider and then accesses multiple applications without entering credentials again. ODC integrates with enterprise identity providers for SSO.

An XML-based standard for exchanging authentication and authorization assertions between an identity provider and a service provider. It is commonly used to enable enterprise single sign-on with ODC.

The secure storage, access, and rotation of credentials such as API keys, passwords, and certificates. Applications retrieve secrets at runtime instead of embedding them in source code or configuration files.

Protecting data while it travels between clients, servers, and external systems. It typically uses TLS to prevent eavesdropping and tampering on network connections.

Protecting stored data on disks, databases, or backups using encryption keys. It ensures that unauthorized parties cannot read data even if they gain access to physical storage.

An ODC connectivity component that lets applications reach resources in a private network without exposing those resources to the public internet. It supports secure hybrid integrations with on-premises systems.

The practice of collecting metrics, traces, and logs to understand application response times, errors, and resource usage. It helps teams detect bottlenecks and verify that service levels are met.

Storing frequently used data in a faster tier, such as memory or an edge server, to avoid repeated expensive calls. Caching improves response times but requires invalidation rules to prevent stale data.

Running work outside the immediate user request, for example through background jobs or messages. It prevents long tasks from blocking the UI and improves resilience when external systems are slow.

The controlled process of moving an application from development through testing to production. It includes versioning, approvals, deployment, monitoring, and rollback so changes are repeatable and auditable.

Continuous integration and continuous delivery are practices that automate building, testing, and releasing application changes. In ODC they reduce manual deployment errors and shorten feedback cycles.

Assigning unique identifiers to modules or applications so that changes can be tracked, compared, and deployed predictably. Versioning supports safe promotion between stages and rollback to a known-good release.

Reverting an application or deployment to a previous known-good version after a failed release or defect. A rollback plan should include data compatibility checks and clear decision criteria.

The ability of an application and its supporting platform to handle increasing load by adding resources or capacity. Scalability can be vertical, by enlarging instances, or horizontal, by adding more instances.

Automatic adjustment of computing resources based on demand signals such as CPU usage, request volume, or queue depth. It helps maintain performance during peaks while controlling cost during quiet periods.

An HTTP-based interface that exposes resources and operations using standard methods such as GET, POST, PUT, and DELETE. ODC service actions can be exposed as REST APIs for integration.

A reusable integration component that wraps an external API or protocol so ODC modules can call it without duplicating low-level details. Connectors simplify authentication, error handling, and data mapping.

An approach that aligns software boundaries with business domains. It uses bounded contexts and ubiquitous language to guide module decomposition, helping teams avoid tangled dependencies and unclear ownership.