Skip to content
02Case Study

Digital Application Architecture

Software ArchitectReactive Web · Mobile · ODC · O11 · iOS · Android

Enterprise digital application architecture for Mobile and Reactive Web experiences, integrating identity, enterprise services, shared capabilities and delivery lifecycles.

Context

Enterprise digital applications are part of ecosystems composed of identity, enterprise services, integrations, legacy systems and different digital channels. Reactive Web and Mobile share architectural principles, but also introduce their own execution, security and distribution characteristics.

The challenge is to allow applications and shared capabilities to evolve sustainably without creating excessive dependencies between channels and enterprise systems.

Architecture Challenge

APPLICATION ARCHITECTURE

Functional domains, responsibilities and application services.

SHARED CAPABILITIES

Identity, session, security, configuration and reusable services.

INTEGRATION ARCHITECTURE

APIs, enterprise services, legacy systems and clear contracts.

REACTIVE WEB & MOBILE

Different channels following consistent architectural principles.

MOBILE-SPECIFIC ARCHITECTURE

Offline, connectivity, device capabilities and native integrations.

PLATFORM EVOLUTION

Architecture adapted to the capabilities and constraints of ODC and O11.

Architecture Overview

The architecture establishes clear boundaries between digital applications, shared capabilities, integration and enterprise systems.

Reactive Web and Mobile share services and architectural principles while each application retains responsibilities related to its functional domains and platform-specific characteristics.

Digital Applications
Reactive Web

Business Capabilities · Functional Domains · Application Logic

Mobile

Business Capabilities · Functional Domains · Application Logic

Shared Application Capabilities

Identity · Session · Security · Configuration

Reusable Services · Shared Logic · Observability

Integration Layer

REST APIs · SOAP · Enterprise Services · External APIs

Contracts · Orchestration · Transformation · Error Handling

Enterprise Systems

Business Systems · Legacy Platforms · Enterprise Services · Enterprise Data

External Services

Identity Providers · Third-party Services · External Platforms · Mobile Services

DIGITAL APPLICATIONS

Reactive Web and Mobile share the same ecosystem, each organizing its own domains and responsibilities.

SHARED CAPABILITIES

Shared capabilities can serve multiple applications when their responsibilities are clearly defined.

INTEGRATION LAYER

Shields applications from the complexity of enterprise and legacy systems.

ENTERPRISE ECOSYSTEM

One layer among many in a wider ecosystem of services and data.

Application Architecture

The architecture of a digital application should reflect the solution's domains and responsibilities rather than simply mirroring the technical structure of the platform used to build it.

FUNCTIONAL BOUNDARIES

Functionality from the same domain should stay close together, with controlled dependencies.

OWNERSHIP & RESPONSIBILITY

Rules, services and data need clear ownership rather than being distributed for implementation convenience.

REUSE WITH BOUNDARIES

Reuse should reduce duplication without creating dependencies that are hard to evolve.

DATA & INTEGRATION BOUNDARIES

Applications should know only the data and contracts their responsibilities require.

Reactive Web

Reactive Web follows the same principles of domain ownership and reuse as the broader enterprise architecture, distributing responsibilities across the application, shared capabilities and enterprise APIs while preserving independent evolution.

Functional Domains · Application Services · Session & Identity · Shared Capabilities · API Consumption · Security Boundaries · Reusable Libraries · Data Ownership

Mobile-Specific Architecture

Mobile applications introduce additional architectural responsibilities because the device becomes part of the solution's execution environment — intermittent connectivity, local persistence, synchronization and device security need to be considered from the beginning of the design.

01

Offline & Data Synchronization

Supporting offline operation means more than simply storing data locally. The architecture needs to define which information remains available on the device, which operations can occur without connectivity and how local changes are later reconciled with remote services.

Initial Sync · Incremental Sync · Local Changes · Pending Operations · Conflict Handling · Retry · Idempotency · Recovery · Local / Remote Consistency

The solution needs to remain predictable even when the network is not.

02

Connectivity & Resilience

Network conditions are inherently variable; connectivity changes, timeouts and transient failures should result in controlled behavior.

Network Status · Timeout · Retry · Pending Operations · Error Recovery · Graceful Degradation

03

Device Security & Local Storage

Persisting information on a device introduces a new security surface. Local information needs to be handled according to its sensitivity.

Local Data · Cache · Preferences · Session Data · Secure Storage

04

Push, Deep Links & Device Capabilities

Push notifications can initiate flows and direct users to specific capabilities; deep links let external channels do the same directly inside the application.

FCM · APNs · Push Tokens · Deep Links · Camera · Biometrics · Files · Location · Sharing · Permissions

05

Plugin & Native Integration Strategy

Plugins and frameworks like Cordova and Capacitor connect the application to platform-specific APIs and native capabilities across iOS and Android, accounting for compatibility, permissions and build impact. Business rules should remain decoupled from these dependencies whenever possible.

Plugins · Cordova · Capacitor · Native SDKs · Permissions · Platform Compatibility

06

Application Lifecycle

Mobile applications need to account for startup, foreground/background transitions, resume and OS termination, with session, synchronization and native integrations responding correctly to each state change.

Platform Architecture — ODC & O11

ODC and O11 have different capabilities and constraints, but the underlying architectural principles remain consistent across both platforms.

OutSystems Developer Cloud

  • Application-oriented architecture
  • Libraries & shared capabilities
  • Cloud-managed runtime
  • Modern delivery model
  • External integrations & platform services

OutSystems 11

  • Modular application architecture
  • Reusable modules & shared services
  • Established enterprise runtime
  • Mature deployment lifecycle
  • External integrations & extensibility mechanisms

Different platforms. Consistent architectural principles.

Delivery Architecture

Reactive Web and Mobile follow different delivery lifecycles: web applications use a publish-and-promote flow, while mobile adds package generation, signing and app-store distribution.

Source / Application
Reactive Web

Build / Publish

Validation

Promotion

Production

Mobile

Mobile Build

iOS

IPA

Signing

App Store

Android

AAB

Signing

Google Play

Release / Update

In mobile environments, plugins, Cordova or Capacitor versions and signing are also part of the delivery lifecycle — a change that appears limited to the application can require a new native build or app-store submission.

Architecture Decisions

01

Organize by Domain, Not by Screen

DECISION

Organize the solution by functional domains and responsibilities.

WHY

Domains evolve as business capabilities, keeping change localized.

TRADE-OFF

Requires stronger ownership discipline.

02

Share Capabilities, Not Entire Applications

DECISION

Share cohesive capabilities rather than coupling entire applications.

WHY

Reuse should reduce duplication without creating structural dependencies.

TRADE-OFF

Shared contracts require governance and compatibility.

03

Treat Offline as an Architectural Mode

DECISION

Treat offline as an explicit architectural mode, not just a caching strategy.

WHY

Offline introduces local state, synchronization, conflicts, retries and consistency concerns.

TRADE-OFF

Adds complexity; should only be applied where it provides real value.

04

Isolate Native Dependencies

DECISION

Isolate plugins, SDKs and Cordova/Capacitor integrations behind well-defined responsibilities.

WHY

Native dependencies evolve independently from functional logic.

TRADE-OFF

Adds abstraction while reducing the impact of replacements and compatibility issues.

Trade-offs

Architecture does not eliminate trade-offs. It makes them explicit so that complexity, autonomy and evolution can be managed deliberately.

ReuseAutonomy
Offline CapabilitySynchronization Complexity
Cross-PlatformNative Capabilities
StandardizationPlatform Flexibility

Technology Landscape

OutSystems Developer Cloud · OutSystems 11 · Reactive Web · Mobile · REST · SOAP · SQL · FCM · APNs · Cordova · Capacitor · iOS · Android · Offline Data Sync · Native Plugins

Closing

Digital application architecture goes beyond the technology used to build an interface — it involves responsibilities, domains, data, integrations and shared capabilities for different solutions to evolve sustainably. Reactive Web and Mobile have different needs, but are part of the same architectural ecosystem.