Architecture Design Fundamentals
Architecture Design Fundamentals tests how you structure an ODC solution before you build it: layering, dependency direction, ownership of logic and data, and fitness for non-functional requirements. The exam expects you to use the OutSystems architecture canvas as a shared vocabulary, not as a diagram to decorate a document.
Core rules
- The canvas has four layers: End-User (screens, blocks, UI flows), Orchestration (processes, dashboards, task-oriented services), Core (business entities and rules), and Foundation (integrations, identity, logging, utilities).
- Dependencies point downward. A Foundation module must not reference Core; Core must not reference Orchestration or End-User.
- Keep business rules in Core, not in screen actions or Foundation adapters.
- Expose the smallest public surface: server actions and public entities only when another module genuinely needs them.
- Prefer acyclic dependencies. A cycle is a design defect, not a deployment inconvenience.
Worked example
A claims app has a screen that validates a policy and writes a claim. The tempting design puts validation in the screen and writes directly to the Core entity. The defensible design puts Claim and Policy entities plus validation in a Core module; an Orchestration module exposes SubmitClaim; the End-User module calls SubmitClaim. Foundation holds the policy-admin API adapter. Reasoning: the screen changes for UX reasons, validation changes for business reasons, and the adapter changes for vendor reasons; separate rates of change justify separate modules.
Traps
- Treating the canvas as mandatory ceremony and creating empty layers.
- Putting integration mapping logic in Core, which couples business rules to a vendor contract.
- Exposing entities for convenience, then discovering every consumer is coupled to the schema.
- Creating a "common" module that everything references and that references everything back.