ODC Architecture Specialist cheat sheet

ODC has exactly three deployment stages - Development, Test and Production - and a revision can only be promoted forward through them in that order.

Architecture Canvas layers top to bottom: End-user (screens and orchestration), Core (business rules and entity ownership), Foundation (generic, business-agnostic reuse); references point downward or sideways within a layer and never upward.

Every deployment creates a new immutable revision; a deployed revision cannot be edited, so rollback means redeploying a previously published revision.

Cross-module logic is reachable only through Service Actions; a server action that is not exposed as a service action cannot be called from another module.

The unit of build, deploy and scale in ODC is the app - not the module and not the individual screen.

ODC runs on provider-managed Kubernetes and managed data services: customers do not size VMs, choose an OS or apply patches, so non-functional targets are met through module boundaries, API contracts and data model design.

Tool split: ODC Studio is the desktop IDE that authors modules; ODC Portal is the browser console that administers the tenant, stages, deployments, users, configuration and logs.

Each stage owns an isolated runtime and database, so test data never reaches Production and environment-specific endpoints are configured per stage.

Number of apps, modules and exposed service actions is the main driver of deployment blast radius: a change inside one app does not require redeploying its consumers, but a changed service action signature does.

ODC module types: Reactive Web App (responsive browser UI), Mobile App (device UI with offline-capable storage) and Library (no UI, packages reusable actions, entities and structures).

A library becomes consumable when selected actions are marked as Service Actions; consumers add a reference to the library and call them like local actions.

Module and app references must form a directed acyclic graph; a cycle blocks independent building and deployment and usually shows that shared logic sits in the wrong layer.

Split into separate apps when release cadence, scaling profile, security boundary or owning team differ; keep modules in one app when they share entities and always ship together.

Layer assignments: orchestration and screens in end-user modules, business rules and entity ownership in core libraries, generic helpers with no domain knowledge in foundation libraries.

Screen Aggregates run when the screen loads; Data Actions fetch later on demand - combine them so the first render stays small and heavy lists load lazily.

Offline mobile is an architecture decision: local storage, synchronisation strategy and conflict resolution must be designed up front, because an offline app is not a web app with a cache.

Decomposition boundary equals deployment boundary equals scaling boundary - three consequences of the same decision, so evaluate a split against all three at once.

Deep call chains across many library hops inflate latency and complicate impact analysis; prefer a shallow graph with a clear owner per capability.

ODC provides a managed relational database per stage with no direct SQL or network access from outside the platform; all reads and writes pass through module logic or the APIs it exposes.

Entities persist across deployments; Static Entities hold deploy-time reference records that are overwritten on every deploy; Structures are in-memory composite types only.

Aggregates compile to SQL executed in the database - filter, sort, group and aggregate server-side; never fetch the full table and filter in the client.

Cross-app data sharing goes through Service Actions or REST APIs rather than shared entities, which keeps each app's schema independently deployable.

External REST services are imported into consumer modules, for example from an OpenAPI definition; calls execute server-side, so credentials are never shipped to the browser.

The Private Gateway is an outbound-only connector installed in a private network, letting ODC apps reach internal services without opening inbound firewall ports.

Bulk, scheduled and long-running integration belongs in Timers and Processes, not in synchronous screen requests that would otherwise wait on a third-party system.

Static Entities must never hold transactional or user-entered data, because a deployment overwrites their records with the model definition.

Design integration contracts for change: version or extend exposed APIs and add fields as optional, so consumers keep working while producers evolve.

Two identity planes exist: end users of apps authenticate through the OIDC provider configured for the tenant (built-in or external, e.g. Entra ID or Okta), while IT users authenticate to Studio and Portal separately.

Authorization is app roles granted to end users plus a server-side check-role; hiding a button or screen element is cosmetic and is bypassed by calling the API directly.

Expose only the service actions external consumers need, and have each one re-check the caller's role and re-validate input, because callers sit outside the module's trust boundary.

Secrets and API credentials belong in ODC Portal configuration injected at deployment; they must never appear in module code, Static Entities or client actions.

All traffic is TLS by default, and the Private Gateway keeps the corporate network closed to inbound connections.

Client-side validation is a usability feature only; every exposed action and API must repeat validation on the server.

Portal audit trails plus log streaming to an external SIEM supply the deployment, access and runtime evidence needed for incident review.

Grant the minimum Portal role per person: administrative capability over stages and deployments should not be given to every developer.

Scaling is per app: modules with very different load profiles placed in one app share the same container set, so separate the apps when their scaling needs diverge.

Latency levers in order of impact: fewer round trips (one aggregate instead of several queries), smaller payloads (fetch only required attributes), pagination, then indexes on filtered and sorted columns.

Entity attributes used in aggregate filters, sorts and joins need indexes; without them response time grows with table size and full scans appear in Production only.

A redeploy does not undo schema changes, so migrations must be backward compatible: add a nullable column, backfill, switch reads, then drop the old column in a later release.

Deployment plans list app revisions in dependency order; a consumer app is deployed after the libraries it references.

Run impact analysis on a changed element before publishing; it lists dependent modules and apps that must be revalidated and redeployed.

Validate performance in the Test stage with production-like data volumes - behaviour at 10,000 rows is invisible at 100.

Rolling back redeploys an earlier revision and restores code only; data left by the newer revision needs an explicit, planned correction.

Watch per-app metrics and streamed logs first when a single app degrades; shared infrastructure is not the usual suspect in ODC.