OutSystems Architecture Specialist (O11) cheat sheet

The OutSystems canvas separates modules into four layers: End-User, Core, Foundation, and Library (plus Service for external exposure); dependencies may only point downward, never upward or sideways within the same layer.

End-User modules contain only UI, screen logic, and session-bound logic; any reusable business rule placed here is an architecture violation because Core modules cannot reference End-User modules.

Core modules expose business entities and actions for a single functional domain; a Core module must never reference another Core module of a different domain - coordinate through Foundation instead.

Foundation modules hold cross-cutting, domain-agnostic logic (utilities, integration adapters, authentication helpers) and must not contain entities owned by a business domain.

Library modules are stateless, side-effect-free, and reusable across applications; they may not reference Core, Foundation, or End-User modules.

Service modules expose REST/SOAP APIs to external systems and should call Core or Foundation actions rather than duplicating business logic.

A Producer module exposes public elements; a Consumer references them. Circular producer/consumer references between modules are blocked by the platform and indicate a layering defect.

Entity ownership rule: exactly one module owns and creates each entity; other modules reference it read-only or via public actions, preventing duplicate entity definitions.

Module granularity heuristic: one Core module per bounded business capability; splitting by screen or by CRUD verb produces chatty dependencies and raises impact analysis cost.

OutSystems scales horizontally by adding front-end servers behind the load balancer; session state is kept in the platform database, so no server affinity (sticky sessions) is required for normal deployment.

Separate the deployment zones: front-end servers run End-User modules; dedicated back-end servers run Core, Foundation, and integration-heavy modules to isolate CPU-bound work from user traffic.

Database scaling rule: read-heavy reporting should use a dedicated read replica or separate reporting database; do not point interactive screens at the same connection pool as batch jobs.

Asynchronous processing (BPT/light processes, timers, or integration queues) moves long-running work off the request thread; any screen action exceeding a few seconds should be evaluated for async offload.

Caching decision rule: cache data that is read far more often than written and tolerates staleness; use the platform cache with explicit invalidation on write, never cache per-user sensitive data in a shared key.

Integration resilience: external calls need timeout, retry with backoff, and circuit-breaker patterns; synchronous chained calls multiply latency, so aggregate or parallelize where the API allows.

Screen aggregation rule: one screen should call one aggregate or a small fixed number of server actions; N+1 query patterns from loops calling the database are the most common scalability defect.

Capacity planning uses measured throughput per server plus headroom (commonly 30-50%); scale out before sustained CPU exceeds roughly 70% during peak to absorb spikes.

The standard pipeline is Develop → Test/QA → Pre-Production → Production; each stage is a separate deployment zone, and code is promoted as a solution, never re-created manually per environment.

Use LifeTime to manage applications, deployments, and environment configuration; environment-specific values belong in the platform's configuration mechanism, not hard-coded in module logic.

Impact analysis before publishing: the platform lists TrueChange warnings/errors and dependency impact; a publish that breaks a public action signature forces republishing all consumers.

Technical debt tracking: IT (integration) and module complexity indicators plus TrueChange warnings form the health baseline; schedule refactoring when warnings accumulate, not after incidents.

Versioning rule: semantic versioning on modules and solutions; breaking public-element changes require a major version and consumer coordination, additive changes a minor version.

Automated regression tests (BDD/test framework) and a smoke suite run in the pipeline gate promotion; a stage is only green when tests and TrueChange are clean.

Performance health is monitored with platform performance monitoring and logs across environments; compare stage metrics to distinguish environment misconfiguration from code regressions.

Deployment rollback depends on a tagged, reproducible version; keep the previous solution version deployable in every stage so rollback is a redeploy, not a code fix.

The architect owns the canvas (layer placement, module boundaries, entity ownership, naming) and publishes it as the reference before development starts.

The developer owns implementation inside an assigned module: internal logic, local variables, and private actions; changing a public element signature requires architect review.

Autonomy boundary rule: a team may change anything private to its own modules; anything consumed by another team (public actions, entities, exposed APIs) is a contract requiring the owner's agreement.

Team topology should mirror module ownership: one team per set of Core modules, with Foundation and Library owned by a platform or shared-services team.

Architecture review gates: canvas conformance at design, public-element changes at code review, and dependency violations blocked in the pipeline rather than discovered in production.

The architect sets non-functional standards (caching policy, async thresholds, integration patterns, naming, error handling) and the developer applies them; deviations are documented exceptions.

Escalation rule: cross-domain data needs go through a Foundation service or an agreed Core public action, never a direct reference between two teams' Core modules.

Governance artifacts the architect maintains: canvas diagram, module inventory with owners, public-element catalog, and the technical-debt backlog prioritized with product.