OutSystems Architecture Specialist (O11) key terms

A diagram that maps an application into layers and modules, showing which module owns each responsibility and how modules depend on one another. It is the primary artifact architects use to communicate structure before implementation begins.

The unit of composition in an OutSystems application: a set of elements such as screens, actions, entities, and integrations that is deployed as a whole and exposes a defined public interface to consumers.

A module that exposes elements for other modules to use. Its public interface is a contract; changing it can break consumers, so it must be versioned and evolved deliberately.

A module that references public elements of another module. Consumers depend on the producer's contract but cannot modify the producer's internals, which keeps change localized.

The subset of a module's elements deliberately exposed to other modules, such as public actions, entities, structures, and screens. Everything else stays private, limiting the blast radius of change.

An arrangement where modules are grouped into layers, typically foundation, core, and end-user, with dependencies pointing only downward. This prevents tangles and lets lower layers be reused across applications.

The lowest layer, holding reusable modules with no dependency on business logic: integrations, utility libraries, and shared entities. It changes rarely and is consumed by everything above it.

The middle layer, containing business services and business entities shared across several end-user modules. It encapsulates business rules so multiple front ends reuse the same logic instead of duplicating it.

The top layer, containing modules that deliver user experience: screens, flows, and orchestration of core services. These modules are application-specific and are not meant for reuse by other applications.

The declared set of public actions, entities, and structures a module offers, independent of its internal implementation. Consumers code against this contract, so internals can be refactored without breaking callers.

A situation where two modules reference each other, directly or through a chain. It couples them into a single unit that must be deployed together and is flagged by architecture analysis tools.

A persistent data model element owned by a module and exposed through its interface when other modules need it. Ownership matters: only the owning module should write to it, others read through service actions.

A built-in analysis view that scores an application's architecture, flagging violations such as circular references, upward dependencies, and modules that break layering rules.

A numeric indicator produced by architecture analysis, reflecting how closely an application follows recommended practices. It is a diagnostic signal, not a certification, and should be read alongside the specific violations listed.

A design approach for exposing data through entities versus service actions: true means the element is public, false means it is private, and none means it is not exposed at all. It clarifies intended coupling between modules.

A deployable container that groups related modules and defines its own lifecycle, versioning, and deployment target. Applications are the unit promoted across environments in the deployment pipeline.

The ability to add more front-end server instances behind a load balancer to handle more concurrent users. It requires stateless session handling and shared state stored outside the web tier.

A design property where no request depends on data held only in a specific server's memory. Any server can serve any request, which is the precondition for safe horizontal scaling.

Data tied to a user's interaction, such as login context or screen input. In scalable designs it is kept small, stored server-side in a shared store, or avoided in favor of client-side tokens.

A component that distributes incoming requests across multiple front-end servers. It enables horizontal scaling and availability, and requires health checks to route around failed nodes.

Designing so the system keeps serving despite component failure, typically through redundancy, health checks, and failover. It targets uptime, whereas scalability targets capacity.

The automatic switch to a redundant component when the primary fails, such as a standby database taking over or a load balancer removing an unhealthy server from rotation.

The layer that persists data, usually the hardest to scale because writes cannot be freely spread across nodes. Read replicas, indexing, and query tuning are the common levers before sharding.

A copy of the database that serves read queries to offload the primary. It introduces replication lag, so code must tolerate slightly stale reads for non-critical data.

Storing frequently used results in fast storage to avoid recomputation or repeated database access. Effective caching needs an invalidation strategy; stale data is the main risk.

Moving slow work such as emails, file generation, or third-party calls off the request path so users are not blocked. It improves perceived performance and smooths load spikes.

A limit on how long a call may take before it is abandoned. Timeouts protect a system from hanging on slow dependencies and are essential when calling external services.

Re-attempting a failed operation, ideally with backoff and only for transient errors. Blind retries can amplify load during an outage, so retries must be bounded and paired with idempotency.

A property where repeating the same operation produces the same result as doing it once. It makes retries and message redelivery safe, especially for payments and record creation.

The OutSystems service that orchestrates deployments between environments, compiling modules and applying changes in dependency order. It is the mechanism behind one-click promotion of applications.

An isolated instance, such as development, test, or production, with its own database and configuration. Applications are promoted between environments rather than edited directly in production.

The console where teams track applications across environments, plan deployments, and manage the pipeline. It gives visibility into what version runs where and who can deploy.

The accumulated cost of shortcuts in design, such as duplicated logic or tangled dependencies, that makes future change slower. Architecture analysis surfaces it early, when it is cheapest to fix.

Restructuring code or module boundaries without changing external behavior. In OutSystems, moving an action to a shared module or inverting a dependency are typical refactors that improve the architecture score.

Determining what else changes when a module's interface changes, by inspecting its consumers. It is the check performed before altering public elements to avoid breaking dependent applications.

The degree to which a team can change and deploy its own modules without coordinating with other teams. It rises when module boundaries are clean and interfaces are stable.

Assigning each module to a specific team accountable for its design, quality, and evolution. Clear ownership reduces conflicting changes and makes the producer's interface a negotiated contract.

The role responsible for application structure, module boundaries, and non-functional qualities such as performance and scalability. Architects set guardrails and review designs rather than writing every module.

A structured check of a design against layering, coupling, and naming standards before or during build. It catches structural problems while they are still inexpensive to correct.