I85PREP
⌘ K
OutSystems Architecture Specialist (O11) study materials
OutSystems Architecture Specialist (O11) study resources

OutSystems Architecture Specialist (O11): Architecture design fundamentals: placing modules on the OutSystems Architecture Canvas

OutSystems Architecture Specialist (O11) · Work through your exam, one topic at a time.

All guide sections

Architecture design fundamentals: placing modules on the OutSystems Architecture Canvas

The Architecture design fundamentals domain checks whether you can take a requirement and place every module, element and integration on the right layer of the OutSystems Architecture Canvas - and defend that placement.

The canvas layers

  • Foundation - modules that wrap external systems (consumed REST/SOAP, database catalogs, extensions). They translate the outside world into a clean interface and hold no business rules.
  • Core - business entities plus the reusable business logic that operates on them, shared by more than one application.
  • End-user - screens, UI flows, and logic that only one application needs.
  • Orchestration - processes that coordinate work across several end-user applications.

References flow downward only. Two modules on the same layer must never reference each other.

Rules examiners reward

  1. Reuse by a second app is the trigger for promotion to Core - not "it might be useful someday".
  2. Entities belong in Core and are consumed through Core; each app does not build its own copy of a customer record.
  3. Only elements marked Public leave a module. Expose the smallest surface that satisfies the consumer.
  4. Granularity follows cohesion and ownership: split a module when it changes for different reasons, or is delivered by a different team.

Worked example

Sales and Support both need a customer's credit limit. A tempting answer has Support reference the Sales module. Reasoning: that is a peer reference on the end-user layer, forbidden by the canvas, and it makes Support's release depend on Sales' release. Correct answer: move the Customer entity and the credit-limit logic into a Core module both apps consume. If the limit comes from an external credit bureau, add a Foundation module wrapping that API, and let Core call it.

Traps

  • Believing elements are public by default - they are not.
  • Putting business rules in Foundation, or HTTP/SOAP plumbing in Core.
  • A single "Common" module every app references: one change, every app redeployed.