Study guide
Modular Dependencies, Public/Private Elements, and Layered Architecture
OutSystems Certified Associate Developer Reactive Web Apps
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
Exam Overview, Logistics, and Study Strategy
2 Chapter 2 — OutSystems Platform and Reactive App Fundamentals
OutSystems Platform Architecture, Service Studio, and Development Tools Client Variables and State Management Screen Lifecycle Events: OnInitialize, OnReady, OnParametersChanged Debugging and Monitoring with the Service Studio Debugger and Service Center
3 Data Modeling
Entities, Attributes, Data Types, and Identifiers Static Entities and Structures Data Relationships, Foreign Keys, and Referential Integrity
4 Chapter 4: Fetching Data
4.1 Aggregates: Filters, Sorting, and Max Records 4.2 Aggregates: Joins, Group By, and Computed Attributes 4.3 Fetching Data on Screens with Data Actions, Caching, and RefreshData 4.4 SQL Queries and External Integrations: REST and SOAP Consumption
5 Logic Flows and Actions
Client Actions, Server Actions, and Action Parameters Logic Flow Control: If, Switch, For Each, and Assign Form Validations: Mandatory, Email Type, and Form.Valid
6 Chapter 6: Error Handling and Advanced Logic
Exception Handling: Exception Handlers, Raise Exception, System vs User Exceptions, AbortTransaction Timers, BPT Processes, Human Activities, and Built-in Functions
7 UI Design: Screen Widgets
Core Screen Widgets: Screen, Container, Expression, If, Link, and Button Forms, Input Widgets, Data Binding, and Feedback Messages List Widget, Pagination, and Screen Navigation Themes, CSS Styling, OutSystems UI, and UI Patterns (Popup/Modal)
8 UI Design: Blocks and Events
Blocks: Creating Reusable UI Components with Input Parameters and Local Variables Block Events and Parent-Screen Communication
9 Architecture, Security, and Lifecycle
Modular Dependencies, Public/Private Elements, and Layered Architecture Role-based Security: Roles, Accessible By, CheckRole, GrantRole, Anonymous Application Lifecycle: 1-Click Publish, LifeTime, Environments, and Versioning
Modular Dependencies, Public/Private Elements, and Layered Architecture
Key Takeaways Explain This Topic AI
OutSystems elements default to Private; setting Public = Yes exposes them to consumer modules via the Add Dependencies window in Service Studio.
The four-layer canvas (End-User, Process, Core, System) enforces one-way downward dependencies — higher layers reference lower layers, never the reverse.
Service Actions are Public Server Actions with a strict input/output contract, recommended for exposing business logic from Core and Process layers.
Expose Read Only on an entity reference blocks Create, Update, CreateOrUpdate, and Delete operations while still allowing Aggregates and SQL queries.
Circular dependencies are forbidden; TrueChange blocks publishing a module that would create an upward dependency in the layered canvas.
Last updated: July 2026
Quick Answer: OutSystems modules expose Public elements (Actions, Entities, Blocks, Screens, Roles) that other modules can reference; Private elements are internal. The platform's four-layer canvas (End-User, Process, Core, System) enforces one-way downward dependencies, preventing circular references. Service Actions expose business logic with a clean input/output contract, and entity references can be marked Expose Read Only to prevent lower layers from mutating core data.
Public vs Private Elements
Every element you create in an OutSystems module — Server Action, Entity, Screen, Block, Role, Structure, Static Entity — has a Public property. When Public is Yes , the element appears in the producer's public API and can be referenced by consumer modules. When Public is No (the default for most elements), the element is visible only inside its owning module. This is the primary encapsulation boundary in OutSystems: modules publish a curated surface and hide their internal implementation.
The producer-consumer model works as follows. A producer module owns the element and sets Public = Yes. A consumer module adds a Reference to that element via the Add Dependencies window in Service Studio. Once referenced, the consumer can call the Action, query the Entity, or drop the Block onto a Screen. The producer retains ownership; the consumer gets a read-only reference it cannot modify. If the producer renames or deletes a public element, TrueChange flags all consumers that depend on it so they can be fixed before publishing.
- Element Type Default Public Typical Use When Public
- Server Action No Expose as Service Action for cross-module business logic
- Entity No Share core data across layers
- Block No Shared UI components across modules
- Role No Security roles consumed by end-user modules
- Structure No DTOs for REST or Service Action contracts
- Layered Architecture (Four-Layer Canvas)
OutSystems prescribes a four-layer canvas to organize modules by responsibility. Dependencies may only point downward — a module in a higher layer may reference modules in the same layer or any lower layer, never upward. This rule is structural, not advisory: TrueChange enforces it at design time.
- Layer Purpose Can Reference
- End-User UI for a specific user role or audience Process, Core, System
- Process Business process orchestration and BPT workflows Core, System
- Core Core entities and shared domain logic System
- System External integrations and platform wrappers Nothing internal
The critical rule: no circular dependencies . Because references flow downward only, a Core module cannot call an End-User Screen, and a System module cannot reference Core entities. This keeps the dependency graph a directed acyclic graph and makes applications maintainable. Service Studio's dependency graph view visualizes every reference your module makes and every module that references yours, so you can trace the full impact of a change before you publish.