ODC, Data Fabric and Architecture User Group

Let's dive deeper into the world of ODC! Ricardo Alves (OutSystems) will join us to tell all about the new Data Fabric. After that, Sezen de Bruijn (OutSystems) will get into the details on how to best design a sturdy architecture within ODC.

1. I N T E R N A L U S E O N L Y
ODC Architecture

2. I N T E R N A L U S E O N L Y
Architecture is about trade-offs
2
Ensuring everyone is on the
latest version

Splitting into loosely coupled
pieces for agility
vs


vs
Giving teams autonomy


Building the system faster
because everything is in the
same context

3. I N T E R N A L U S E O N L Y
I N T E R N A L U S E O N L Y
3
Crash course DDD:

4. I N T E R N A L U S E O N L Y
I N T E R N A L U S E O N L Y
4

5. I N T E R N A L U S E O N L Y
I N T E R N A L U S E O N L Y
5

6. I N T E R N A L U S E O N L Y
I N T E R N A L U S E O N L Y
6

7. I N T E R N A L U S E O N L Y
I N T E R N A L U S E O N L Y
7
Exam

8. Trade-off 2: To split or not to split

B2E B2C Auto Health Multirisk
Broker Portal Client Website
Client Mobile App
Auto
Auto Simulator
Auto Services
Health
Health Simulator
Health Services
Multirsk
Multirsk Simulator
Multirsk Services
Auto Plates IS
Mobile Plugins
Legacy Calc Engine Xif
Broker Portal Client Auto Health Multirisk
Plugins
Integration External Logic
Business
Owner 1
Business
Owner 2
Business
Owner 4
Business
Owner 3
Business
Owner 5
Business
Sponsor 1
Business
Sponsor 1
Business
Sponsor 2
Business
Sponsor 3
Business
Sponsor 4

9. Option 1: O11 Domains Architecture Sample
Step 3 - Map Bounded Contexts to Applications and Libraries
B2E B2C Auto Health Multirisk
Broker Portal Client Website
Client Mobile App
Auto
Auto Simulator
Auto Services
Health
Health Simulator
Health Services
Multirsk
Multirsk Simulator
Multirsk Services
Auto Plates IS
Mobile Plugins
Legacy Calc Engine Xif
Broker Portal Client Auto Health Multirisk
Plugins
Integration External Logic
Business
Owner 1
Business
Owner 2
Business
Owner 4
Business
Owner 3
Business
Owner 5
Business
Sponsor 1
Business
Sponsor 1
Business
Sponsor 2
Business
Sponsor 3
Business
Sponsor 4
Broker
Portal
Client
web
Auto Health Multirisk
Client
Mobile

10. 10
Option 2: O11 Domains Architecture Sample
Step 3 - Map Bounded Contexts to Applications and Libraries
B2E B2C Auto Health Multirisk
Broker Portal Client Website
Client Mobile App
Auto
Auto Simulator
Auto Services
Health
Health Simulator
Health Services
Multirsk
Multirsk Simulator
Multirsk Services
Auto Plates IS
Mobile Plugins
Legacy Calc Engine Xif
Broker Portal Client Auto Health Multirisk
Plugins
Integration External Logic
Business
Owner 1
Business
Owner 2
Business
Owner 4
Business
Owner 3
Business
Owner 5
Touch &
Face Id
Plugin
Camera
Plugin
Auto Plates
Connector
Calc Engine
External
Logic
Business
Sponsor 1
Business
Sponsor 1
Business
Sponsor 2
Business
Sponsor 3
Business
Sponsor 4
Broker
Portal
Client
web
Auto Health Multirisk
Client
Mobile

11. 11
Option 3: O11 Domains Architecture Sample
Step 3 - Map Bounded Contexts to Applications and Libraries
B2E B2C Auto Health Multirisk
Broker Portal Client Website
Client Mobile App
Auto
Auto Simulator
Auto Services
Health
Health Simulator
Health Services
Multirsk
Multirsk Simulator
Multirsk Services
Auto Plates IS
Mobile Plugins
Legacy Calc Engine Xif
Broker Portal Client Auto Health Multirisk
Plugins
Integration External Logic
Business
Owner 1
Business
Owner 2
Business
Owner 4
Business
Owner 3
Business
Owner 5
Touch &
Face Id
Plugin
Camera
Plugin
Auto Plates
Connector
Calc Engine
External
Logic
Business
Sponsor 1
Business
Sponsor 1
Business
Sponsor 2
Business
Sponsor 3
Business
Sponsor 4
Broker
Portal
Client
web
Auto Health Multirisk
In this use case, we have detected that a domain would have to be
mapped into two ODC Apps since we have a mobile application inside.
Due to that reason, further decoupling is required.
Client
Mobile

12. I N T E R N A L U S E O N L Y
Trade-off 2: To split or not to split
12
Insurance
Services
Simulation
Services
CRM
Services
Web
Theme
Mobile
Theme
Patterns
Broker
Portal
Client
web
Health Auto Multirisk
Client
Mobile
Client (browser) Broker (browser)Client (mobile)
Touch &
Face Id
Plugin
Camera
Plugin
Auto Plates
Connector
Calc Engine
External
Logic
Plates API

13. I N T E R N A L U S E O N L Y
Team 1
Front-end Team
13
ODC Architecture Blueprint
Step 4 - Design ODC Architecture Blueprint
Insurance
Services
Simulation
Services
CRM
Services
Web
Theme
Mobile
Theme
Patterns
Broker
Portal
Client
web
Health Auto Multirisk
Client
Mobile
Client (browser) Broker (browser)Client (mobile)
Touch &
Face Id
Plugin
Camera
Plugin
Auto Plates
Connector
Calc Engine
External
Logic
Plates API
Library
Application
Strong dependency
Weak dependency
Team 2
Team 2 Team 4
Team 3
Team 5
Team 5 Team 3 Team 2

14. I N T E R N A L U S E O N L Y
Team 1
Front-end Team
14
ODC Architecture Blueprint
Step 4 - Design ODC Architecture Blueprint
Insurance
Services
Simulation
Services
CRM
Services
Web
Theme
Mobile
Theme
Patterns
Broker
Portal
Client
web
Health Auto Multirisk
Client
Mobile
Client (browser) Broker (browser)Client (mobile)
Touch &
Face Id
Plugin
Camera
Plugin
Auto Plates
Connector
Calc Engine
External
Logic
Plates API
Library
Application
Strong dependency
Weak dependency
Team 2
Team 2 Team 4
Team 3
Team 5
Team 5 Team 3 Team 2

15. I N T E R N A L U S E O N L Y
Architecture Basic Concepts
15

16. I N T E R N A L U S E O N L Y
16
Application
●Encapsulate business concepts, UI, logic and data of a specific business context
●Are loosely coupled between each other by definition
●Have independent life cycles
●Can be used to:
○Hold user interfaces, Screens and business Blocks
○Expose APIs in a microservices approach trough Service Actions
○Implement asynchronous processing using Timers
Applications
What is an application in ODC?
Build applications to solve a business use cases
User Interfaces
Web / Mobile
Microservices
Service Actions / REST APIs
Asynchronous
Processing

17. I N T E R N A L U S E O N L Y
17
Application Elements
Processes Interface Logic Data
Application
ScreenTimer Service Action Entity
Block
Theme
Client Action
Server Action
Structure
Static Entity
Rest Expose
Rest Consume
Entity Diagram
Exception
Role
Client Variable
Settings
Resource
Image
Script
External Site
Element can be reused in other applications

18. I N T E R N A L U S E O N L Y
Each Application is packaged
into a container when Published
Only weak references are
allowed between Applications
ApplicationApplication
ODC KB
ODC Application
Applications are packaged into loosely coupled containers

19. I N T E R N A L U S E O N L Y
19
Library
What is a Library in ODC?
Code to be reused by multiple applications or libraries
Reusable UI
Blocks / Patterns / Layouts
Themes Integration Wrappers Logic Utilities
●Are used to share code with applications or other libraries
●Are packaged into a version that’s included into the application container
●Are strongly coupled with consumer applications for fast code execution
●Can be used to implement business agnostic components like:
○Reusable UI: Blocks, Patterns and Layouts
○Themes
○Integration Wrappers,
○Logic Utilities

Libraries
●Libraries are used to share code with applications or other libraries 

●Libraries are packaged together with an application container when a user deploys an application

●

●Libraries have the foundations to be versioned, reducing the impact on applications and teams that are
not yet ready to upload the new version

●Libraries can have settings and are configurable at the application level 


20. I N T E R N A L U S E O N L Y
20
Library Elements
Processes Interface Logic Data
ScreenTimer Service Action Entity
Block
Theme
Client Action
Server Action
Structure
Static Entity
Rest Expose
Rest Consume
Entity Diagram
Exception
Role
Client Variable
Settings
Resource
Image
Script
External Site
Library
Element can be reused in other applications or libraries

21. I N T E R N A L U S E O N L Y
A Library version is packaged when
Library is Published
21
Library Application
Only strong references are allowed
when consuming Libraries
ODC Library
Libraries are packaged into each consumer Application
The packaged Library version is packaged
together with the Application container
when Application is Published

22. I N T E R N A L U S E O N L Y
22
Library Application
Development
Quality Production
…
A Library version is packaged together with the
Application container when Application is Published
Each Application container is
deployed into each stage and
respective configurations are applied
ODC CI/CD
Build once in Development and deploy to following stages
Different Configuration Values
can be set at each stage

23. I N T E R N A L U S E O N L Y
23
Different configuration values can be set in
each Stage that the Application is Deployed,
overriding default value defined in
development time through Service Studio
Quality Production
…
Development
Application
2. Apply Values1. Edit Configurations
3. New Configuration Applied
Applying configurations through the
portal is an asynchronous process, so
values might not be updated immediately
after being set in the portal
Configurations
Applying configurations through the Portal

24. I N T E R N A L U S E O N L Y
24
Application
Slack
Slack API
Although the Settings are defined at the
Library level, since the Application is
consuming the Library, we are able to
configure Settings at Application Level
through the Portal
SlackToken (Secret)
IsActive (Setting)
Settings can be marked as being
secrets, providing a secure way to
store sensitive information
encrypted in a vault
Slack
Slack
Settings
Configuring Library Settings and using them to Store Application Secrets

25. I N T E R N A L U S E O N L Y
25
Application
Slack
Slack API
Although the Integration is being used at
the Library level, since the Application is
consuming the Library, we are able to
configure the Integration Endpoint at
Application Level through the Portal
Slack
Integrations
Configuring Library Integrations Endpoints

26. I N T E R N A L U S E O N L Y
Trade-off 1: Let’s play: should it be an
app or a library?
When I release everyone will have to adopt
My elements are business aware
I have my own runtime context

26
Library
Application
When I release everyone can adopt at their own pace
I contain business agnostic elements
I do not have my own runtime context

27. I N T E R N A L U S E O N L Y
Let’s play: should it be an app or a
library?
27
Sharing Theme and Patterns
across Applications

28. I N T E R N A L U S E O N L Y
28
Theme
Application 1 Application 2
Patterns
Business agnostic Patterns
Libraries promote reusability since
they can be consumed by multiple
applications
Using Libraries to share Look & Feel
Sharing Theme and Patterns across Applications
Client (browser) Client (browser)
Library
Application
Strong dependency
Weak dependency

29. I N T E R N A L U S E O N L Y
29
Mobile
Theme
Web
The base theme has the common CSS that will be
inherited by the consumer themes.
The base theme can be completely custom or it can be
OutSystems UI (the default option)
Using Theme inheritance
Themes can inherit from each other, making it easier to share common parts of look & feel between apps

Client (browser) Client (browser)
Library
Application
Strong dependency
Weak dependency
Mobile
Web
Theme
Base
Theme
Each consumer theme will inherit the
common CSS from the base theme, while
implementing the specific CSS and/or
overriding CSS coming from base theme

30. I N T E R N A L U S E O N L Y
Let’s play: should it be an app or a
library?
30
Sharing Theme and Patterns
across Applications
Reusable blocks
that contain data

31. I N T E R N A L U S E O N L Y
31
Sharing blocks across Applications
Blocks can only be shared by consuming Libraries, thus data has to be passed through input parameters
Application 1
Client (browser)
Application 2
GetHeaderInfo
Header
HeaderInfo
Header Information is retrieved from
the GetHeaderInfo Service Action and
passed as an input to the Header
Block when the screen is rendered
Client (browser)
Header

Header
HeaderInfo
Header Block is defined at
Library Level (Patterns)
Application 2 has the Header Info and
shares it with other Applications
through a Service Action.
In Application 2, Header Information
can be used directly
Patterns
Library
Application
Strong dependency
Weak dependency

32. I N T E R N A L U S E O N L Y
32
Sharing a App Switcher Menu
Having a common menu across applications can be achieved by sharing a block using a Library
Application 1 Application 2 Application 3
Menu Items are defined in static
links, using external Urls, pointing to
each application Screen
Client (browser) Client (browser) Client (browser)
Menu

Menu
Library
Application
Strong dependency
Weak dependency

33. I N T E R N A L U S E O N L Y
Let’s play: should it be an app or a
library?
33
Sharing Theme and Patterns
across Applications
Reusable blocks
that contain data
Integration Service
Wrappers that promote
reusability and reduce
third-party change impacts

34. I N T E R N A L U S E O N L Y
34
ERP API
ERP
Connector This type of integrations are the ideal
candidates to be Forge Components
Direct Integration
Integration Service Wrappers promote reusability and reduce third-party change impacts

Library
Application
Strong dependency
Weak dependency
An Integration Service Wrapper promotes
reusability of Integrations across applications
through a strong dependency, avoiding potential
performance overhead of using a weak
dependency.

Impacts driven by changes on third-party APIs
are also mitigated by this encapsulation
Application 1 Application 2

35. I N T E R N A L U S E O N L Y
35
Each system is interfaced with a
different library. All libraries provide
an API with the same signatures
This library abstracts the existence of
different systems into a single service,
routing requests to the correct library
Transparency Service Pattern
Abstracting different systems into a single service definition
Notification
Teams APISlack API Email Service
Slack Teams Email
Application 2
Library
Application
Strong dependency
Weak dependency
Application 1

36. I N T E R N A L U S E O N L Y
Let’s play: should it be an app or a
library?
36
Sharing Theme and Patterns
across Applications
Reusable blocks
that contain data
Integration Service
Wrappers that promote
reusability and reduce
third-party change impacts
Sharing data between
systems

37. I N T E R N A L U S E O N L Y
37
Sharing reference data
Ref. Data is typically business agnostic, with slow change pace, that can be reused across multiple use cases
Application 1 Application 2 Application 3
Client (browser) Client (browser) Client (browser)
Library
Application
Strong dependency
Weak dependency
Location
RefData
Country
City
To promote reusability, applications can
be used to hold and share Reference
Data across multiple applications
Reference Data Applications should
follow the design process steps, to
ensure: concepts are grouped the right
way, ownership is well defined and
lifecycle independence is respected
Reference data can be leveraged by
consumer applications in aggregates
by referencing the public entities

38. I N T E R N A L U S E O N L Y
38
Sharing business entities with plain data
Consuming public business entities has a lower development effort and should be used for entities with plain
data and stable data model
Application 1 Application 2 Application 3
Client (browser) Client (browser) Client (browser)
Library
Application
Strong dependency
Weak dependency
Billing Supplier
An Entity exposed as Public should have a
low change pace as business evolves. Should
share plain data that doesn’t involve
complex business rules and doesn't require
high business knowledge from consumer
Teams to make sense of data.
Consuming Public Entities is easy and
reduces development effort as consumer
applications can use entities in
aggregates or Advanced queries in
read-only mode, facilitating data
mashup

39. I N T E R N A L U S E O N L Y
39
Sharing business entities with business rules
Sharing data through public entities can reduce business encapsulation depending on the use case
Application 1 Application 2 Application 3
Client (browser) Client (browser) Client (browser)
Library
Application
Strong dependency
Weak dependency
Billing
InvoiceHeader
InvoiceItems
In these use cases, sharing public Entities
can cause teams to lose isolation by
potentially spreading business rules
across the consumer applications, making
it harder to maintain and keep quality.
Consumers can also suffer more impacts
of frequent breaking changes of data
model that happen at business pace
InvoicePayments
⚠ 

We should be careful when sharing data that
requires business knowledge by the
consumer Teams (e.g.: involving multiple
joins and filters to make sense of data or
when there are validations or calculations
or other business rules)

40. I N T E R N A L U S E O N L Y
40
Sharing business entities with business rules
Exposing business data through service actions ensures higher business concepts encapsulation
Application 1 Application 2 Application 3
Client (browser) Client (browser) Client (browser)
Library
Application
Strong dependency
Weak dependency
Billing
InvoiceHeader
InvoiceItems
The business data model is not
exposed directly to consumer
applications, keeping a black box
abstraction, by having the business
rules centralized in a single place.
Only the relevant data attributes
should be included.
Exposing a Service Action to be consumed
by the applications has some extra
development effort over consuming public
entities, specially for data mashup, but it
can improve reusability and isolation of
business logic.
InvoicePayments
GetInvoicesWithDetails

InvoicesWithDetailsList

InvoiceWithDetails


41. I N T E R N A L U S E O N L Y
Let’s play: should it be an app or a
library?
41
Sharing Theme and Patterns
across Applications
Reusable blocks
that contain data
Integration Service
Wrappers that promote
reusability and reduce
third-party change impacts
Sharing data between
systems

42. I N T E R N A L U S E O N L Y
42
ERP API
ERP
Connector
In some scenarios, having a cold cache for our data is very
important to prevent overloading our source APIs, but
also to ensure a better performance when we have slow
APIs.

This approach should be used when our Application can
cope with some delay to have data updated. Otherwise a
direct integration is required for real-time data integration.
Integration with Cold Cache
Using a Cold cache to reduce load on API and increase Application Performance
Library
Application
Strong dependency
Weak dependency
Application 1
Customer

In this approach, a timer runs frequently to pull data
from the API connector to populate an entity with data
coming from the source API.

For better performance and more frequent updating a
differential synchronization approach is
recommended. Although the API needs to support it, by
allowing to query for new, updated and deleted records
since last call.
The synchronization logic can be
optimized by leveraging the built-in
bulk inserts (CreateOrUpdateSome…)
SyncCustomer


43. I N T E R N A L U S E O N L Y
43
Application 1 Application 2 Customer
Each Application has its own role.
Although being different roles, they
can have the same name.
Customer
ODC Portal
Application 1 Customer
Application 2 Customer
✔

✔

Client (browser) Client (browser)
Assigning each role in each application to
the user will enable us to use them to
validate our use cases in each application
Validating Personas Across Applications
Using the out-of-the box feature to validate persona level access

44. I N T E R N A L U S E O N L Y
44
Application 1 Application 2
Customer
Specific features might require access validation with greater
granularity, to accomplish that a role that represents the
feature access is created in both applications. Then the
access is also validated on both applications
Agent
ODC Portal
Application 1 Agent
Application 1 CustomerReports
✔

✔

Client (browser)
In the ODC portal, the roles are assigned to
user in each application so that the
validation can be done in each application
Validating Specific Permissions Across Applications
Using the out-of-the box feature to validate higher granularity level of access
CustomerReports CustomerReports
GetCustomerReports

Application 2 CustomerReports✔


45. I N T E R N A L U S E O N L Y
45
Application 1 Application 2 Customer
IsCustomerRole?

This Approach should be avoided, since each time the
IsCustomerRole is being called through a ServiceAction,
overhead is potentially introduced and applications lose
the ability to scale independently
Specially taking into consideration that checking for a role
can be executed many times in the context of a Screen
⚠ 

Client (browser) Client (browser)
Pitfalls of Validating Roles Across Applications
Why should avoid using service actions to share roles?

46. I N T E R N A L U S E O N L Y
A fun new architecture
challenge!
(for certain values of fun)
46

47. I N T E R N A L U S E O N L Y
47
●Producers and consumer Applications are loosely coupled
●No point-to-point integrations, it's easy to add new consumers to the system using Publish /
Subscribe pattern
●Consumers respond to events immediately as they arrive, making it ideal for Asynchronous &
Parallel Processing use cases
●Highly scalable and distributed systems with increased Parallel Batch Processing capabilities
Benefits of Event Driven Architecture
Event Driven Architecture with ODC
Leveraging ODC Events capability to implement Event Driven Architecture patterns
Publish / Subscribe
Asynchronous &
Parallel Processing
Parallel Batch
Processing
Trigger Event
NEW

48. I N T E R N A L U S E O N L Y
Events in ODC
Internal Properties of Events in ODC
Event Payload
Maximum payload of 10KB per Event
Only primitive types (except binaries) supported as Event parameters (no Structures, Lists or Entity
Records allowed)
Event Queues
Each Event Type has its own queue
Maximum Queue size of 10K events per Event Type
Event Delivery
Each Event is delivered only once to consuming Applications
Delivery Order of the Events is not guaranteed
Maximum of 10 retry attempts per Event
The intervals between retry attempts are determined by the Backoff Policy (2, 4 , 8, 16, 32 min)
Event Execution
Maximum 100 threads per Application for Event execution
Maximum duration of each Event Execution thread is 2 min
NEW
ODC KB

49. I N T E R N A L U S E O N L Y
49
Event Architecture Basic Concepts
How to represent Events in ODC Architecture Blueprints?
Application 1
Client (browser)
Application 2
Client (browser)
Library
Application
Strong dependency
Weak dependency
NEW
Application 1
Client (browser)
Application 2
Client (browser)
Event Stream
Publish Subscribe
How Events actually work
How we chose to represent it,
keeping it simple.
Notice the dotted line and the
Icon on top to differentiate from
other types of weak dependencies.

50. I N T E R N A L U S E O N L Y
50
Event Architecture Basic Concepts
How do Events work in ODC?
Application 1
Client (browser)
Application 2
Event
Client (browser)
Library
Application
Strong dependency
Weak dependency
Event
An Event can also be triggered and
consumed in same Application, launching
an asynchronous Event execution thread
Event
An Event can be consumed
in any Application
An Event can only be
triggered in the Application
it has been defined
NEW

51. I N T E R N A L U S E O N L Y
Thank you!
51