Architecture
What the exam tests
The Architecture domain checks whether you can place modules on the OutSystems Architecture Canvas, enforce dependency direction, choose module types, and use the Architecture Dashboard to keep the portfolio healthy. Expect questions on layer responsibilities, exposure, and dependency violations.
Core rules
- Foundation layer: reusable entities, integrations, and utilities; no UI; must not depend on Core or End-User.
- Core layer: business services that orchestrate Foundation; expose actions, not raw entities.
- End-User layer: screens and channel-specific logic; consumes Core and Foundation; never the reverse.
- Dependencies point downward. Circular dependencies are defects, not style issues.
- Module types: Reactive Web and Mobile for UI, Service for integrations and APIs, Library for shared logic, Extension for native code.
- Expose only public elements; keep interfaces small and stable.
Worked example
A Customer Portal needs customer balances. Put the portal screen in End-User. Create a Core Customers service with a GetBalance action that validates the caller and calls a Foundation integration. Do not let the screen read the Foundation entity directly. Reasoning: the Core action is the reusable business contract; it prevents UI code from bypassing authorization and lets other channels reuse the same rule.
Traps that cost marks
Putting business rules in screen actions; exposing entities for convenience; creating one module per screen; treating Architecture Dashboard warnings as cosmetic; and letting two Core modules call each other.