Application Design and Development
Domain 2 tests architectural judgment in Service Studio: how to compose modules, expose elements, and keep dependencies healthy. Questions often present a module diagram or a design scenario and ask what should change.
Core rules
- OutSystems' architecture canvas separates End-User, Core, Foundation, and Library layers. End-User modules own screens and UI flows; Core modules own business processes; Foundation modules own reusable entities and integrations; Library modules hold pure utilities.
- Dependencies should point downward only. An End-User module may reference Core; Core may reference Foundation; no lower layer should call upward.
- Expose only the public elements consumers need. Use public server actions, entities, structures, and blocks deliberately; avoid making whole modules public by habit.
- Module roles enforce authorization inside a module; application roles aggregate them across an application. Prefer application roles for end-user permissions.
- References are explicit. Adding a reference creates a compile-time dependency; circular references are a design smell and often a deployment hazard.
Worked example
An order application has Orders_UI (screens), Orders_Core (order validation), and Orders_Foundation (Order entity and payment integration). A developer wants Orders_Core to call a screen action in Orders_UI to refresh the basket. That would invert the dependency. Better: move the refresh logic into a Core server action, expose it, and have the UI call it. Reasoning: UI-specific screen actions are not reusable business services and would force Core to depend on End-User, breaking the canvas and complicating deployment.
Traps
- Putting business rules in screen actions because it is faster.
- Exposing entities directly to many modules instead of a Core API.
- Creating circular references to reuse a single action.
- Using module roles alone for application-wide permissions.
- Forgetting that public elements become contracts that are hard to change.