Disclaimer
Between March 12 and 13, 2026, during a late-night architecture review, the model I had been developing finally crystallized.
What had initially started as two SAP-oriented patterns converged into a five-layer semantic integration architecture, culminating in DEIP – Domain Enterprise Integration Pattern.
On February 7, 2026 the scope of this work was limited to two patterns designed for SAP landscapes:
DCRP – Domain-Centric Routing PatternPDCP – Package Domain-Centric Pattern
Both focused on solving structural governance problems in SAP API Management and SAP Cloud Integration.
In just 36 days this initial nucleus evolved into a fully formalized five-layer semantic control architecture, designed to address a problem that many integration architects recognize but rarely formalize: integration sprawl.
This problem is not new.
For 17 years I have observed the same structural pattern repeating itself across different generations of SAP integration technologies:
SAP XI – fragmented Software ComponentsSAP PI/PO – interface and configuration proliferationSAP BTP Integration Suite – proxy, package, credential and artifact sprawl inside CPI landscapes
Each generation improved the technology stack, but the structural indexing problem remained the same: integrations were organized by system or project, rather than by domain intent.
During these 36 days of research and experimentation, this recurring chaos was distilled into a single architectural model.
At the center of this model sits DEIP, the parent architecture layer responsible for governing the three execution patterns:
DEIP — Semantic Control Plane Decision Model
└── Decision Pipeline
Intent
→ Interaction Type
→ Quality Profile
→ Integration Capability
→ Protocol Profile
→ Platform Binding
└── SDIA — Semantic Domain Integration Architecture
(DEIP Reference Architecture)
├── GDCR — Gateway Domain-Centric Routing
│ Reference Implementation — recommended starting point
├── DDCR — Domain Driven-Centric Router
│ Routing and capability resolution engine
└── ODCP — Orchestration Domain Composition Pattern
Cross-domain orchestration layer
└── Execution Platforms
SAP BTP · AWS · Azure · Kong · Kafka · IoT · AI/LLM · etc.
Together, these patterns form a domain-centric semantic control plane that sits above any specific execution platform.
From this point of closure — looking at SAP landscapes where the required capabilities already exist but are often applied without consistent domain semantics — this final blog post of the series begins.
Disclaimer SAP
SAP BTP Integration Suite already provides all the capabilities necessary to implement and validate this architecture in practice.
The platform offers:
a mature API Management layera powerful Cloud Integration runtimeEvent Meshsecurity servicesand strong governance tooling.
The problem has never been the SAP platform itself.
Instead, the issue often lies in how integrations are indexed and governed.Many landscapes organize integrations by projects and systems, rather than by domain intent, which leads to proxy, package and credential sprawl even on top of a strong platform.
This same concern was raised earlier in January 2026 in my SAP Community article:
SAP BTP – Integration Suite: Clean Architecture vs The Frankenstein Landscape.
As a way of acknowledging the SAP ecosystem that shaped much of this work over the past 17 years, I am making a small professional commitment.
Within schedule constraints, I will offer five 1:1 discussion sessions, free of charge, for SAP architects interested in discussing how the following patterns can be applied in real landscapes:
These sessions are not intended as training or presentations.Participation assumes bringing concrete architectural questions, since the discussion will focus on the structural decision model behind the framework — beginning with the fundamental key I propose:
What is the domain intent of this integration?
Alignment with SAP Strategic Directions
This work aligns directly with three strategic directions already promoted by SAP:
Clean CoreDEIP keeps protocol complexity and integration decision logic outside of S/4HANA by moving these concerns into a semantic control plane on SAP BTP.This allows the core ERP to remain standard while integrations stay governed and evolvable.RISE with SAPBy indexing integrations on domain intent rather than on individual systems, DEIP provides RISE transformation programs with a structured way to rationalize legacy interfaces during cloud migrations.ISA-MDEIP complements ISA-M by operating as a decision layer above the integration scenario model.While ISA-M classifies integration scenarios, DEIP maps them to capabilities, protocol profiles and platform bindings, ensuring that integration architectures remain domain-driven and consistent across platforms.
Dedication and Acknowledgement
Dedication
This work is dedicated to my father, Brigadier Ricardo Holanda Viana,
The Commander, whose discipline, courage and leadership shaped much of the character behind this journey.
Acknowledgement
Beyond its personal dedication, this work stands on the shoulders of foundational contributions that have shaped modern enterprise architecture and integration thinking.
Key references that served as intellectual guidance in the development of this model include:
Hohpe & Woolf (2003) — Enterprise Integration Patterns
Martin Fowler (2002) — Patterns of Enterprise Application Architecture
Eric Evans (2003) — Domain-Driven Design
Sam Newman (2015) — Building Microservices
Kreps et al. (2011) — Kafka: A Distributed Messaging System for Log Processing
Istio Team (2017) — Service Mesh control plane architectures
Zhamak Dehghani (2022) — Data Mesh
These works served as conceptual references and navigational points during the research and development process.
The central motivation behind this work was to revisit these architectural patterns and integration models and explore how they could be structurally combined into a coherent enterprise architecture perspective, organized around a single primary key:
the intent of the domain.
In this model, domain intent becomes the organizing principle that allows architectural decisions — from interaction patterns to protocol profiles and platform bindings — to be navigated consistently across the enterprise integration landscape.
Ricardo Luz Holanda Viana – March 2026
Introduction
Enterprise integration landscapes have evolved significantly over the past two decades.
Technologies have improved, platforms have matured, and new capabilities have been added to integration stacks across the industry.
Yet one structural problem persists across almost every enterprise landscape: integration sprawl.
Interfaces are frequently indexed by systems, projects, or technical artifacts, rather than by the intent of the domain they serve. Over time this leads to landscapes filled with proxies, packages, credentials, endpoints and flows that are technically functional, but structurally difficult to understand, govern and evolve.
This blog introduces DEIP — Domain Enterprise Integration Pattern, a vendor-agnostic semantic meta-framework structured across five architectural levels, governed entirely as a metadata control plane, designed to bring structural clarity to modern enterprise integration landscapes.
At its core, DEIP proposes a simple but powerful shift:
integration decisions should begin with domain intent, not with technology.
From that starting point, integration architectures can be navigated through a structured decision pipeline that determines:
the interaction type
the required quality characteristics
the integration capability
the protocol profile
and finally the platform binding.
This model forms a semantic control plane that governs runtime architectures such as SDIA, GDCR, DDCR and ODCP, while remaining independent from any specific execution platform.
The goal of this article is not to dive into every technical detail of the model.
Instead, it aims to provide architects with a clear conceptual overview of the architecture and the problem it addresses.
A complete technical companion document — expected in the coming months — will describe in detail how to map domains, structure the decision model, and navigate the architectural layers in real enterprise landscapes.
Until then, the most important idea to retain is simple:
everything begins with a single primary key: the intent of the domain. – “The Domains never lies”
Interpretation Note
This timeline should not be interpreted as positioning DEIP as “higher or better” to the foundational work of Hohpe & Woolf (2003).
Enterprise Integration Patterns defined 65 fundamental patterns describing how messages move through enterprise integration systems. Their work remains one of the most important references in the field and continues to guide integration architecture today.
The name Domain Enterprise Integration Pattern (DEIP) was deliberately chosen as a tribute to that work. Hohpe and Woolf defined the patterns that govern how messages travel inside enterprise integration systems.
DEIP builds on that legacy by addressing a different architectural question that emerged as enterprise landscapes evolved into multi-cloud, multi-vendor environments and AI-driven systems.
While Enterprise Integration Patterns describe how messages move across integration infrastructure, DEIP proposes a structural model for how domain intent moves across the enterprise landscape.
In this model, the domain becomes the primary architectural key, allowing integration decisions to be navigated consistently across interaction types, capabilities, protocol profiles and platform bindings.
In that sense, DEIP should be understood as an evolutionary architectural layer built on top of the foundations established by Enterprise Integration Patterns, extending their ideas into modern enterprise integration landscapes.
This work is therefore presented not as a replacement of those foundations, but as a continuation of them — an attempt to take the principles established in 2003 and structure them for the next generation of enterprise integration architectures.
What is DEIP?
DEIP – the Domain Enterprise Integration Pattern – is a semantic decision architecture designed to bring structural clarity to modern enterprise integration landscapes. Instead of organizing integrations by systems, projects or technical artifacts, DEIP proposes that every integration decision starts from a different primary key: the intent of the domain. In this model, the domain becomes the organizing principle used to navigate integration decisions across the entire landscape, and a semantic control plane replaces ad‑hoc design inside individual flows, proxies or API configurations.
The DEIP Decision Pipeline (6 stages)
At the center of DEIP is a seven‑stage decision pipeline:
Intent → Interaction Type → Quality Profile → Integration Capability → Protocol Profile → Platform Binding
Each stage answers a different question and progressively transforms domain intent into a concrete integration implementation:
Intent – What is the semantic purpose of the integration?
Examples: invoice.read.finance, orders.create.ecommerce, iot.sensor.stream, security.identity.authenticate.
Interaction Type – Which interaction family does it belong to?
Examples: request, command, event, stream, batch, workflow, replication.
Quality Profile – What non‑functional characteristics are required?
Examples: low latency, high throughput, at‑least‑once delivery, strict ordering, strong authentication, data sovereignty.
Integration Capability – Which abstract integration capability is needed?
Examples: API mediation, event streaming, CDC replication, long‑running workflow, IoT ingestion, AI tool routing, security authentication/authorization.
Protocol Profile – Which concrete protocol or messaging style implements that capability?
Examples: HTTP/REST, gRPC, OData, Kafka, MQTT, AMQP, ETL/CDC, OpenID Connect.
Platform Binding – On which runtime platform will this flow execute?
Examples: SAP API Management, SAP Cloud Integration, SAP Event Mesh, Kafka cluster, IoT broker, identity provider, Kubernetes/Istio.
Execution Binding – What is the concrete execution artifact or RouteID that binds this decision to a real endpoint or flow, without exposing internal topology to consumers?
By navigating these seven stages, architects can consistently determine how integrations should be implemented, independent of specific vendors or products.
Metadata as the Control Mechanism
DEIP does not introduce another integration product. It operates purely as a semantic control plane expressed as metadata that describes the integration landscape. This metadata acts as the control map of the architecture and can live in a structured database, a metadata catalog, a governance repository, or—even in the early stages—a well‑structured spreadsheet.
Metadata control plane = a table where you store your enterprise integration decisions.
Can be:
– Excel ← it’s metadata
– Google Sheets ← it’s metadata
– Database ← it’s metadata
– Redis / KVM ← it’s metadata
– Sticky note on the wall ← technically also metadata
The fancy name is just that — a table where you store the map of intentions.
The sophistication is not WHERE you store it. It’s WHAT you store and how DDCR uses it.
A simple starting point can look like this:
DomainIntentInteractionCapabilityProtocolPlatform
OrdersCreate OrderAsync, eventEvent publicationKafkaAWSCustomersUpdate ProfileSync APIRequest/ResponseRESTSAP BTPPaymentsPayment ConfirmationEvent (notification)Event notificationAMQPAzureIoTSensor Telemetry IngestionStreamTelemetry stream ingestionMQTT → KafkaIoT Hub + Kafka/K8sIoTDevice Firmware UpdateCommandReliable device commandMQTT QoS 1IoT HubServiceProvision Application SpaceAsync workflowProvisioning orchestrationREST + WebhookSAP BTPServiceRestart Critical ServiceCommandOperational runbookgRPC/RESTKubernetes / IstioSecurityUser AuthenticationRequestAuthentication serviceOpenID ConnectIdentity ProviderSecurityThreat Detection AlertEvent (alert)Security event routingHTTPS / JSONSIEMSecurityCredential RotationBatch / workflowSecret lifecycle managementAPI / CLIVault / KMS
From Decision Model to Runtime Architecture
DEIP itself is not a runtime system. It is an architectural decision model that governs runtime architectures such as:
SDIA – Semantic Domain Integration Architecture
GDCR – Gateway Domain‑Centric Routing
DDCR – Domain‑Driven Centric Router
ODCP – Orchestration Domain Composition Pattern
These patterns implement the decisions derived from the DEIP pipeline inside real integration platforms (for example, SAP API Management, SAP Cloud Integration, Event Mesh, IoT brokers, service meshes and identity providers). The semantic control plane decides what should happen and where; the runtime patterns execute those decisions.
The core principle behind all of this remains intentionally simple and universal:
every integration decision starts from a single primary key — the intent of the domain.
DEIP and DDCR — A Simple Mathematical Model
Although DEIP is primarily an architectural decision model, its pipeline can also be expressed as a simple mathematical function that transforms domain intent into a concrete integration implementation.
Friends from SAP, I’m going to present the mathematical formulas that I derived. But don’t worry — the solution is DEIP itself. The formulas are only here as a visual aid to help understand the model.
What matters is the architectural, structural and execution vision behind it. At this point, the way I see integration architecture is very simple: I see patterns, domains and mathematics.
Mathematics is universal – 2 + 2 = 4 anywhere in the world.
Look at the table below for example. The Order to Cash process is essentially the same anywhere in the world.So how does DEIP interpret this?
No matter where you are in the world, regardless of language or platform, the entry point for any Order to Cash call is:
/<domain>/<entity>/<action>/<target>
Example:
/sales/order/create
What does this mean inside SAP API Management ?
Only one proxy is required. It can be defined using a single OpenAPI or Swagger specification with an entry point like:
/sales/orders/create/<target>
The routing is static, and a JavaScript policy (DDCR) resolves the final destination.
This means you can place 20 vendors behind a single API proxy in SAP API Management.
The code can include custom headers for tracking, and additional headers can also be added if needed.
This approach eliminates proxy sprawl at the root.
That is the idea behind DDCR.
In practice, the DDCR runtime proved this approach works. A simple JavaScript policy implementation processed around 2,067,904 requests across 8 platforms and 5 programming languages, running continuously for about 29 hours, withzero routing failures — 158 network-layer failures only (ECONNRESET/ETIMEDOUT)
The full implementation details, experiments and runtime evidence are available in the GitHub repository associated with this work.
DEIP(Intent, Context) → Implementation
The DEIP pipeline is a sequence of deterministic functions. Each stage is a formal reduction where context constrains the valid outputs:
f₁ : I × C → T
Intent + Context → Interaction Type
f₂ : I × T × C → Q
Intent + Interaction Type + Context → Quality Profile
f₃ : I × T × Q → Cap
Intent + Interaction Type + Quality Profile → Integration Capability
f₄ : Cap → Pprot
Integration Capability → Protocol Profile
f₅ : Pprot × C → Pplat
Protocol Profile + Context → Platform Binding
In this model:
I = Domain Intent
C = Context (environment, constraints, policies)
T = Interaction Type
Q = Quality Profile
Cap = Integration Capability
Pprot = Protocol Profile
Pplat = Platform Binding
DDCR Resolution Model – Remember in SAP APIM it’s just the javascript policy the name is my creation just it.
Once the decision pipeline produces a platform binding, the DDCR engine resolves the final runtime configuration using deterministic key resolution.
{ f(key) → value }
Where the key represents the resolved integration identity derived from the DEIP pipeline, and the value represents the runtime configuration to be applied (routing target, protocol adapter, credentials, endpoint, or orchestration behavior).
Applying DEIP in Practice
Once the DEIP decision pipeline is defined, the next step is applying its outcomes inside the runtime architecture.
DEIP itself does not execute integrations.
Instead, it acts as a semantic control plane that guides how runtime components should behave.
In practice, the pipeline outputs are implemented through the SDIA architecture and its execution patterns.
DEIP → SDIA
The first layer where DEIP becomes operational is SDIA (Semantic Domain Integration Architecture).
SDIA represents the runtime architecture organized by domain, where integrations are grouped and governed according to their domain intent.
Instead of organizing integration artifacts by systems or projects, SDIA structures them by domains, such as:
Orders
Payments
Customers
Logistics
Notifications
Each domain becomes a semantic boundary where integration decisions derived from the DEIP pipeline are applied consistently.
SDIA → GDCR
At the gateway layer, DEIP decisions guide GDCR (Gateway Domain-Centric Routing).
GDCR is responsible for routing requests according to the domain intent.
Instead of routing based only on technical endpoints, GDCR uses the domain structure to determine where requests should flow.
Example:
/<domain>/<entity>/<action>/<target | sender>
/sales/orders/create/salesforce
/hr/customers/update/workday
/finance/payments/authorize/stripe
/iot/sensors/stream/mqtt
/iot/devices/command/firmware
Here the domain is the primary routing key.
Entao com essa organizacao o que é feito dentro do SAP APIM ? Que na minha opniao é a melhor ferramenta no quisito User Design e configuracao de rotas estativas ? Vou te explicar.
Proxy Sprawl (1 proxy por backend or Contract)
/sap-s4hana/orders/create
/salesforce-crm/orders/create
/oracle-erp/orders/create
/legacy-system/orders/create
↑ 4 proxies · 4 contracts · 4 versioning
After with DEIP + SDIA + GDCR and DDCR
GDCR (1 proxy por domínio)
/sales/<entity>/<action>/<vendor>
↑ 1 proxy · 1 contract · new vendor via metadata – KVM for SAP APIM
For example – Domain: SALES – Process O2C, the same sample works for SALES – Lead to Opportunity (L2O) – Opportunity to Quote (O2Q) – Quote to Order (Q2O) etc…
So you create one proxy – gdcr-proxy-domain-sales-o2c, it means what ever application, vendor, client, modile etc that goes for the intent domain SALES for APIM always will use only the entry dor /sales/ but than how to routing this ?
Static routing over the entity for the HTTP path /sales/orders… /sales/customers…/sales/invoices…/sales/princing
Entry door: https://<apim>/282cc9datrial/sales/
What does this configuration mean?
This is a static routing rule condition in the API Proxy design. This single proxy — SALES O2C — supports all calls from anywhere, covering 13 business processes from the O2C domain.
What does this still mean ?
500 applications · 1 proxy · 13 routing rules = End of proxy sprawl. The rest DDCR — JavaScript — resolves alone. Don’t worry.
Why did I decide to segregate the proxy per business domain? To avoid the sprawl of a single proxy responsible for all calls. This segregation also keeps everything more organized.
Does DDCR work with OpenAPI and Swagger ?
Yes — the JavaScript is the routing engine. There is no connection with the contract or SLA of the specification. But the mindset must change: you don’t create a specification per vendor — you create a specification per domain.
This means the specification, proxy, and DDCR JavaScript are immutable. If anything new comes to onboard — add one string in the KVM. That’s it. As simple as 2+2=4. This is mathematics.
But my company is working with IOT etc… so follow the same process, create proxy, add the routing, what will be the domain /LLM/ thats it
gdcr-ai-llm-proxy-domain-unified
https://<apim>/282cc9datrial/llm
SDIA → DDCR
Once a request enters the domain structure, DDCR (Domain Driven Centric Router) resolves the final integration configuration.
DDCR acts as a deterministic resolution engine.
It takes the resolved domain identity and looks up the metadata produced by the DEIP pipeline to determine:
protocol – http
endpoint – any destiny
Conceptually:
Domain + Intent → Configuration
So let’s check again what was discussed above we are speaking about SALES – O2C means the entry door for SAP APIM:
Entry door: https://<apim>/282cc9datrial/sales/
Than we have this cenario – 1 proxy – routing ( /orders/** – / customers/** – /deliveries/** 😞
https://<sapapim>/sales/orders/create/salesforce
https://<sapapim>/sales/orders/update/salesforceemea
https://<sapapim>/sales/orders/create/microsoft
https://<sapapim>/sales/customers/sync/s4hana
https://<sapapim>/sales/customers/sync/shopify
https://<sapapim>/sales/deliveries/transfer/fedex
DDCR Keys — KVM (determinísticas e machine-computed)
dcrporderscid01salesforce:http
dcrporderscid02sfemea:http
dcrporderscid03microsoft:http
dcrpcustomerssid04s4hana:cxf
dcrpcustomerssid05shopify:http
dcrpdeliveriestid06fedex:http
Resolved URLs — CPI (execution-ready)
https://<cpi>/http/dcrp/orders/c/id01
https://<cpi>/http/dcrp/orders/u/id02
https://<cpi>/http/dcrp/orders/c/id03
https://<cpi>/cxf/dcrp/customers/s/id04
https://<cpi>/http/dcrp/customers/s/id05
https://<cpi>/http/dcrp/deliveries/t/id06
Again — this logic is pure mathematics. The only way to fail is a wrong intent HTTP path or a wrong string in the KVM, that triggers in the 3rd step the FAST-FAIL M2M in ~0.1ms, the backend don’t even know about this call. It never fails. Over 2 million calls across 5 different API platforms from the market — and everything else I tested — zero routing failures.
SDIA → ODCP
Some integrations require orchestration across multiple domains. This is where ODCP — Orchestration Domain-Centric Pattern — operates.
ODCP governs three things simultaneously:
1. Package Topology — One Domain, One Package
Before: After:
Salesforce_Orders_Pkg → nx.sales.o2c.integrations
SAP_S4HANA_Orders_Pkg → (same package — Sales domain)
SAP_ECC_FI_AR_v2_Package → nx.finance.r2r.integrations
FedEx_Shipping_Integration → nx.logistics.le.integrations
Ariba_Procurement_Pkg → nx.procurement.s2p.integrations
Temp_QA_DoNotDelete → eliminated
39 packages → 4. Package count becomes invariant — it scales with domains, not vendors.
ODCP defines a structured package naming convention that encodes domain identity, business process, and platform context into a single readable string:
Component
Description
Example Values
Constraints
prefix
Organization or platform identifier
nx, sap, az, aws, mule
Lowercase, alphanumeric
domain
Business domain
sales, finance, logistics, procurement, hr, manufacturing
Lowercase, no spaces
process
Primary business process subdomain
o2c, r2r, le, s2p, h2r, p2p
Standard process codes
integrations
Fixed suffix
integrations
Always literal ‘integrations’
[prefix].[domain].[process].integrations Multi-division — same domain, same business process, one division owns the integration:
[prefix-company].[division].[domain].[businessprocess].[integration]
Multi-division — same orchestration tenant, multiple divisions, same domain:
[prefix-company].[division].[core].[domain]
2. iFlow DNA — Deterministic Artifact Naming
POST /sales/orders/create/salesforce
→ id01.o2c.salesforce.order.s4hana.c.in.sync
POST /finance/invoices/create/s4hana
→ id13.r2r.s4hana.invoice.target.c.in.sync
Every artifact is traceable from semantic URL → DDCR key → iFlow DNA. No more Salesforce_Order_Sync_v3_FINAL_USE_THIS.
id[seq].[subdomain].[sender].[entity].[receiver].[action].[direction].[sync|async]
Example: id01.o2c.salesforce.order.s4hana.c.in.sync
iFlow DNA Component Reference
Component
Description
Example Values
Constraints
Role
id[seq]
Sequential flow identifier within the package
id01, id02, id99
Pattern idd{2}
Links to DDCR KVM iflowid
subdomain
Business process code
o2c, r2r, le, s2p
Standard process codes
Process context
sender
Source system or vendor
salesforce, sap, workday, shopify
Lowercase, alphanumeric
Integration source
entity
Business entity being processed
order, invoice, customer, shipment
Lowercase, singular
Business object
receiver
Target backend system
s4hana, oracle, stripe, target
Lowercase, alphanumeric
Integration target
action
Canonical action code
c, r, u, d, s, n, a, t
Single character — DDCR codes
Operation type
direction
Message flow direction
in, out
Lowercase
Flow direction
sync|async
Execution mode
sync, async
Lowercase
Processing mode
iFlow DNA — Implementation Proofs
Semantic Address
iFlow DNA
POST /sales/orders/create/salesforce
id01.o2c.salesforce.order.s4hana.c.in.sync
GET /finance/invoices/get/s4hana
id10.r2r.s4hana.invoice.target.r.in.sync
POST /finance/invoices/create/s4hana
id13.r2r.s4hana.invoice.target.c.in.sync
PUT /sales/customers/update/salesforceus
id02.o2c.salesforce.customer.s4hana.u.in.sync
POST /logistics/shipments/sync/microsoft
id21.le.microsoft.shipment.s4hana.s.in.async
POST /procurement/requisitions/create/ariba
id31.s2p.ariba.requisition.s4hana.c.in.sync
PUT /procurement/contracts/update/workday
id35.s2p.workday.contract.s4hana.u.in.sync
POST /finance/journals/post/s4hana
id14.r2r.s4hana.journal.target.a.in.sync
Each iFlow DNA name is directly traceable to its semantic address in the GDCR facade and its KVM routing key in the DDCR engine. The id[seq] component is the explicit link: id01 in the iFlow DNA corresponds to iflowid id01 in the KVM key dcrporderscsalesforceid01:http.
4.5 The Semantic Chain — End-to-End Traceability
Semantic Address
DDCR KVM Key
DDCR Resolved Path
ODCP iFlow DNA
POST /sales/orders/create/salesforce
dcrporderscsalesforceid01:http
/http/dcrp/orders/c/salesforce/id01
id01.o2c.salesforce.order.s4hana.c.in.sync
POST /finance/invoices/create/s4hana
dcrpinvoicescs4hanaid13:cxf
/cxf/dcrp/invoices/c/s4hana/id13
id13.r2r.s4hana.invoice.target.c.in.sync
PUT /sales/customers/update/salesforceus
dcrpcustomersu salesforceusid02:http
/http/dcrp/customers/u/salesforceus/id02
id02.o2c.salesforce.customer.s4hana.u.in.sync
POST /procurement/requisitions/create/ariba
dcrprequisitions cariba id31:cxf
/cxf/dcrp/requisitions/c/ariba/id31
id31.s2p.ariba.requisition.s4hana.c.in.sync
Business intent enters at the semantic address. Metadata decides at the DDCR engine. Domain governs at the ODCP orchestration layer. Technology becomes background. Semantics become the integration language — end to end.
3. Credential Segmentation — Sub-Domain Tiered
cr.sales.orders.rw — Orders only · 30 days rotation
cr.sales.analytics.ro — Analytics only · 90 days rotation
cr.finance.ap.rw — Accounts Payable only · 30 days rotation
39 credentials → 12. One rotation failure affects only one sub-domain — never the entire landscape.
The result: Business intent enters at the semantic URL. DDCR resolves. ODCP governs the artifact. Technology becomes background.
Credential Naming Convention
Technical user names follow the same domain‑centric semantic pattern as packages and flows:
Examples:
cr.sales.orders.rw – Sales / Orders / Read‑Writecr.finance.ap.rw – Finance / Accounts Payable / Read‑Writecr.finance.reporting.ro – Finance / Reporting / Read‑Onlycr.logistics.shipments.rw – Logistics / Shipments / Read‑Write
The naming convention makes credential ownership, scope, and permission level immediately readable from the identifier, eliminating the opacity of names like iflow_cred_12 or api_user_SF_orders.
Three Pillars of ODCP Credential Governance
Pillar
Principle
Outcome
Consolidation
Group flows by domain sub-domain, not by project or vendor
Eliminates credential silos and naming chaos
Standardization
Enforce consistent naming: prefix.domain.subdomain.permission
Enables systematic credential audit and rotation
Governance
Assign ownership by sub-domain architect; enforce RBAC on credential mutation
Centralized control, isolated blast radius, audit-ready
SAP-Specific Artifact Scope
In SAP BTP Cloud Integration, the iFlow DNA naming convention extends to all integration artifacts within the package — not only iFlows. Script collections, value mappings, message mappings, data stores, communication channels, technical users, and even internal variables adopt the same domain‑centric prefixing (for example, vm.sales.order.status, sc.sales.order.transformation, cr.sales.orders.rw). This makes the entire CPI artifact space navigable by business domain rather than by technical type or vendor.
Artifact Type
Naming Convention
Integration Flows (iFlows)
id[seq].[subdomain].[sender].[entity].[receiver].[action].[direction].[mode]
Value Mapping Tables
vm.[domain].[entity].[field] — e.g. vm.sales.order.status
Script Collections
sc.[domain].[function] — e.g. sc.sales.order.transformation
Message Mappings
mm.[domain].[entity].[sender].[receiver] — e.g. mm.sales.order.sfdc.s4h
Technical Users
cr.[domain].[subdomain].[permission] — e.g. cr.sales.orders.rw
Internal Variables
var.[domain].[context].[name] — e.g. var.sales.orders.batchsize
SDIA — COMPLETE ARCHITECTURE
End-to-End Semantic Flow
The Semantic Domain Integration Architecture (SDIA) preserves business domain semantics across every layer of the enterprise integration stack. ODCP is the final governance layer in this chain — ensuring that semantic continuity extends from the API consumer address to the backend execution artifact.
Human Semantic Address
POST /sales/orders/create/salesforce
GDCR
Gateway Layer
Semantic gateway facade — domain-centric API governance
Single proxy per domain · semantic URL abstraction · fail-fast enforcement
DDCR
Resolution Engine
Deterministic 7-stage runtime resolution — metadata-driven backend binding
dcrporderscsalesforceid01:http → /http/dcrp/orders/c/salesforce/id01
ODCP
Orchestration Layer
Domain-centric package topology — iFlow DNA — tiered credential governance
nx.sales.o2c.integrations · id01.o2c.salesforce.order.s4hana.c.in.sync
Enterprise Systems
SAP S/4HANA · Salesforce · Oracle · Workday · Stripe · Legacy Systems · Cloud Platforms
The Result
When combined, these layers create a complete architecture:
DEIP — Semantic Control Plane → What · Why · Which
↓
SDIA — Domain Runtime Architecture → Organized by domain intent
↓
GDCR — Gateway Layer → 1 proxy per domain · immutable
↓
DDCR — Resolution Engine → f(key) → value · zero failures
↓
ODCP — Orchestration Layer → 1 package · DNA naming · tiered credentials
↓
Execution Platforms → SAP · AWS · Azure · Kong · IoT · AI/LLM
↓
Result = Sales + Sales + Sales + Sales
The full end-to-end — based on the intention of the Sales domain. The technology does not matter. What matters is what the domain needs.
Conclusion
Every enterprise integration landscape on Earth converges to the same six failure modes. Not because of bad engineers. Not because of bad platforms. Because the organizing principle was always wrong.
Technology was never the primary key. The domain always was.
DEIP does not add a new tool to your stack. It changes the question you ask before you build anything:
What is the domain intent of this integration?
Answer that first. Everything else — protocol, platform, proxy, credential, artifact — becomes a consequence.
The domain never lies. It never has. We just forgot to ask it first.
Start Here — Reading Order
⚠️Before reading anything else — start with GDCR.
GDCR is where everything began. Originally developed as DCRP and PDCP — two SAP-specific patterns — it evolved into the foundation of the entire SDIA ecosystem. Without reading GDCR first, the other documents will not make sense. This is not a suggestion. It is a requirement.
Reading order:
🔗GDCR — DOI: 10.5281/zenodo.18582492 ← Start here🔗DDCR — DOI: 10.5281/zenodo.18864832🔗ODCP — DOI: 10.5281/zenodo.18876594🔗SDIA — DOI: 10.5281/zenodo.18877635🔗DEIP — DOI: 10.5281/zenodo.19004802 ← This document
5 Architecture Discussion Slots
I am offering five free 1:1 sessions for senior architects and integration experts who have read the documents and want to discuss the architecture at a structural and abstract level.
I am not excluding any professional from the APIM or CPI space — but I want to be clear: these sessions are not about how to configure APIM routing or how to get the DDCR JavaScript running. The documents cover that.
What I want to discuss is DEIP — the decision pipeline, the semantic control plane, and the structural model behind it. If that is the conversation you want to have, send me an email.
This is not a course. This is not training. The documents are already published and available for free.
If you have read the material and want to discuss architecture — send me an email: rhviana@gmail.com
What comes next
In approximately two months I will release a companion document covering how to build the complete DEIP integration map and navigate all four architectural layers in practice. I cannot commit to an exact date yet.
After that — my focus moves to IEEE. The mathematics behind DDCR and DEIP deserve a formal academic submission. That is where this work goes next.
The domain never lies.
Ricardo Luz Holanda Viana — March 2026 — Warsaw, Poland
DisclaimerBetween March 12 and 13, 2026, during a late-night architecture review, the model I had been developing finally crystallized.What had initially started as two SAP-oriented patterns converged into a five-layer semantic integration architecture, culminating in DEIP – Domain Enterprise Integration Pattern.On February 7, 2026 the scope of this work was limited to two patterns designed for SAP landscapes:DCRP – Domain-Centric Routing PatternPDCP – Package Domain-Centric PatternBoth focused on solving structural governance problems in SAP API Management and SAP Cloud Integration.In just 36 days this initial nucleus evolved into a fully formalized five-layer semantic control architecture, designed to address a problem that many integration architects recognize but rarely formalize: integration sprawl.This problem is not new.For 17 years I have observed the same structural pattern repeating itself across different generations of SAP integration technologies:SAP XI – fragmented Software ComponentsSAP PI/PO – interface and configuration proliferationSAP BTP Integration Suite – proxy, package, credential and artifact sprawl inside CPI landscapesEach generation improved the technology stack, but the structural indexing problem remained the same: integrations were organized by system or project, rather than by domain intent.During these 36 days of research and experimentation, this recurring chaos was distilled into a single architectural model.At the center of this model sits DEIP, the parent architecture layer responsible for governing the three execution patterns: DEIP — Semantic Control Plane Decision Model
└── Decision Pipeline
Intent
→ Interaction Type
→ Quality Profile
→ Integration Capability
→ Protocol Profile
→ Platform Binding
└── SDIA — Semantic Domain Integration Architecture
(DEIP Reference Architecture)
├── GDCR — Gateway Domain-Centric Routing
│ Reference Implementation — recommended starting point
├── DDCR — Domain Driven-Centric Router
│ Routing and capability resolution engine
└── ODCP — Orchestration Domain Composition Pattern
Cross-domain orchestration layer
└── Execution Platforms
SAP BTP · AWS · Azure · Kong · Kafka · IoT · AI/LLM · etc. Together, these patterns form a domain-centric semantic control plane that sits above any specific execution platform.From this point of closure — looking at SAP landscapes where the required capabilities already exist but are often applied without consistent domain semantics — this final blog post of the series begins.Disclaimer SAPSAP BTP Integration Suite already provides all the capabilities necessary to implement and validate this architecture in practice.The platform offers:a mature API Management layera powerful Cloud Integration runtimeEvent Meshsecurity servicesand strong governance tooling.The problem has never been the SAP platform itself.Instead, the issue often lies in how integrations are indexed and governed.Many landscapes organize integrations by projects and systems, rather than by domain intent, which leads to proxy, package and credential sprawl even on top of a strong platform.This same concern was raised earlier in January 2026 in my SAP Community article:SAP BTP – Integration Suite: Clean Architecture vs The Frankenstein Landscape.As a way of acknowledging the SAP ecosystem that shaped much of this work over the past 17 years, I am making a small professional commitment.Within schedule constraints, I will offer five 1:1 discussion sessions, free of charge, for SAP architects interested in discussing how the following patterns can be applied in real landscapes:These sessions are not intended as training or presentations.Participation assumes bringing concrete architectural questions, since the discussion will focus on the structural decision model behind the framework — beginning with the fundamental key I propose:What is the domain intent of this integration?Alignment with SAP Strategic DirectionsThis work aligns directly with three strategic directions already promoted by SAP:Clean CoreDEIP keeps protocol complexity and integration decision logic outside of S/4HANA by moving these concerns into a semantic control plane on SAP BTP.This allows the core ERP to remain standard while integrations stay governed and evolvable.RISE with SAPBy indexing integrations on domain intent rather than on individual systems, DEIP provides RISE transformation programs with a structured way to rationalize legacy interfaces during cloud migrations.ISA-MDEIP complements ISA-M by operating as a decision layer above the integration scenario model.While ISA-M classifies integration scenarios, DEIP maps them to capabilities, protocol profiles and platform bindings, ensuring that integration architectures remain domain-driven and consistent across platforms.Dedication and AcknowledgementDedicationThis work is dedicated to my father, Brigadier Ricardo Holanda Viana,The Commander, whose discipline, courage and leadership shaped much of the character behind this journey.AcknowledgementBeyond its personal dedication, this work stands on the shoulders of foundational contributions that have shaped modern enterprise architecture and integration thinking.Key references that served as intellectual guidance in the development of this model include:Hohpe & Woolf (2003) — Enterprise Integration PatternsMartin Fowler (2002) — Patterns of Enterprise Application ArchitectureEric Evans (2003) — Domain-Driven DesignSam Newman (2015) — Building MicroservicesKreps et al. (2011) — Kafka: A Distributed Messaging System for Log ProcessingIstio Team (2017) — Service Mesh control plane architecturesZhamak Dehghani (2022) — Data MeshThese works served as conceptual references and navigational points during the research and development process.The central motivation behind this work was to revisit these architectural patterns and integration models and explore how they could be structurally combined into a coherent enterprise architecture perspective, organized around a single primary key:the intent of the domain.In this model, domain intent becomes the organizing principle that allows architectural decisions — from interaction patterns to protocol profiles and platform bindings — to be navigated consistently across the enterprise integration landscape.Ricardo Luz Holanda Viana – March 2026IntroductionEnterprise integration landscapes have evolved significantly over the past two decades.Technologies have improved, platforms have matured, and new capabilities have been added to integration stacks across the industry.Yet one structural problem persists across almost every enterprise landscape: integration sprawl.Interfaces are frequently indexed by systems, projects, or technical artifacts, rather than by the intent of the domain they serve. Over time this leads to landscapes filled with proxies, packages, credentials, endpoints and flows that are technically functional, but structurally difficult to understand, govern and evolve.This blog introduces DEIP — Domain Enterprise Integration Pattern, a vendor-agnostic semantic meta-framework structured across five architectural levels, governed entirely as a metadata control plane, designed to bring structural clarity to modern enterprise integration landscapes.At its core, DEIP proposes a simple but powerful shift:integration decisions should begin with domain intent, not with technology.From that starting point, integration architectures can be navigated through a structured decision pipeline that determines:the interaction typethe required quality characteristicsthe integration capabilitythe protocol profileand finally the platform binding.This model forms a semantic control plane that governs runtime architectures such as SDIA, GDCR, DDCR and ODCP, while remaining independent from any specific execution platform.The goal of this article is not to dive into every technical detail of the model.Instead, it aims to provide architects with a clear conceptual overview of the architecture and the problem it addresses.A complete technical companion document — expected in the coming months — will describe in detail how to map domains, structure the decision model, and navigate the architectural layers in real enterprise landscapes.Until then, the most important idea to retain is simple:everything begins with a single primary key: the intent of the domain. – “The Domains never lies” Interpretation NoteThis timeline should not be interpreted as positioning DEIP as “higher or better” to the foundational work of Hohpe & Woolf (2003).Enterprise Integration Patterns defined 65 fundamental patterns describing how messages move through enterprise integration systems. Their work remains one of the most important references in the field and continues to guide integration architecture today.The name Domain Enterprise Integration Pattern (DEIP) was deliberately chosen as a tribute to that work. Hohpe and Woolf defined the patterns that govern how messages travel inside enterprise integration systems.DEIP builds on that legacy by addressing a different architectural question that emerged as enterprise landscapes evolved into multi-cloud, multi-vendor environments and AI-driven systems.While Enterprise Integration Patterns describe how messages move across integration infrastructure, DEIP proposes a structural model for how domain intent moves across the enterprise landscape.In this model, the domain becomes the primary architectural key, allowing integration decisions to be navigated consistently across interaction types, capabilities, protocol profiles and platform bindings.In that sense, DEIP should be understood as an evolutionary architectural layer built on top of the foundations established by Enterprise Integration Patterns, extending their ideas into modern enterprise integration landscapes.This work is therefore presented not as a replacement of those foundations, but as a continuation of them — an attempt to take the principles established in 2003 and structure them for the next generation of enterprise integration architectures.What is DEIP?DEIP – the Domain Enterprise Integration Pattern – is a semantic decision architecture designed to bring structural clarity to modern enterprise integration landscapes. Instead of organizing integrations by systems, projects or technical artifacts, DEIP proposes that every integration decision starts from a different primary key: the intent of the domain. In this model, the domain becomes the organizing principle used to navigate integration decisions across the entire landscape, and a semantic control plane replaces ad‑hoc design inside individual flows, proxies or API configurations.The DEIP Decision Pipeline (6 stages)At the center of DEIP is a seven‑stage decision pipeline:Intent → Interaction Type → Quality Profile → Integration Capability → Protocol Profile → Platform Binding Each stage answers a different question and progressively transforms domain intent into a concrete integration implementation:Intent – What is the semantic purpose of the integration?Examples: invoice.read.finance, orders.create.ecommerce, iot.sensor.stream, security.identity.authenticate.Interaction Type – Which interaction family does it belong to?Examples: request, command, event, stream, batch, workflow, replication.Quality Profile – What non‑functional characteristics are required?Examples: low latency, high throughput, at‑least‑once delivery, strict ordering, strong authentication, data sovereignty.Integration Capability – Which abstract integration capability is needed?Examples: API mediation, event streaming, CDC replication, long‑running workflow, IoT ingestion, AI tool routing, security authentication/authorization.Protocol Profile – Which concrete protocol or messaging style implements that capability?Examples: HTTP/REST, gRPC, OData, Kafka, MQTT, AMQP, ETL/CDC, OpenID Connect.Platform Binding – On which runtime platform will this flow execute?Examples: SAP API Management, SAP Cloud Integration, SAP Event Mesh, Kafka cluster, IoT broker, identity provider, Kubernetes/Istio.Execution Binding – What is the concrete execution artifact or RouteID that binds this decision to a real endpoint or flow, without exposing internal topology to consumers?By navigating these seven stages, architects can consistently determine how integrations should be implemented, independent of specific vendors or products.Metadata as the Control MechanismDEIP does not introduce another integration product. It operates purely as a semantic control plane expressed as metadata that describes the integration landscape. This metadata acts as the control map of the architecture and can live in a structured database, a metadata catalog, a governance repository, or—even in the early stages—a well‑structured spreadsheet.Metadata control plane = a table where you store your enterprise integration decisions. Can be:
– Excel ← it’s metadata
– Google Sheets ← it’s metadata
– Database ← it’s metadata
– Redis / KVM ← it’s metadata
– Sticky note on the wall ← technically also metadata The fancy name is just that — a table where you store the map of intentions.The sophistication is not WHERE you store it. It’s WHAT you store and how DDCR uses it.A simple starting point can look like this:DomainIntentInteractionCapabilityProtocolPlatformOrdersCreate OrderAsync, eventEvent publicationKafkaAWSCustomersUpdate ProfileSync APIRequest/ResponseRESTSAP BTPPaymentsPayment ConfirmationEvent (notification)Event notificationAMQPAzureIoTSensor Telemetry IngestionStreamTelemetry stream ingestionMQTT → KafkaIoT Hub + Kafka/K8sIoTDevice Firmware UpdateCommandReliable device commandMQTT QoS 1IoT HubServiceProvision Application SpaceAsync workflowProvisioning orchestrationREST + WebhookSAP BTPServiceRestart Critical ServiceCommandOperational runbookgRPC/RESTKubernetes / IstioSecurityUser AuthenticationRequestAuthentication serviceOpenID ConnectIdentity ProviderSecurityThreat Detection AlertEvent (alert)Security event routingHTTPS / JSONSIEMSecurityCredential RotationBatch / workflowSecret lifecycle managementAPI / CLIVault / KMS Over time, this table evolves into a living architectural map of the enterprise integration landscape, where each row is a governed decision path through the DEIP pipeline.From Decision Model to Runtime ArchitectureDEIP itself is not a runtime system. It is an architectural decision model that governs runtime architectures such as:SDIA – Semantic Domain Integration ArchitectureGDCR – Gateway Domain‑Centric RoutingDDCR – Domain‑Driven Centric RouterODCP – Orchestration Domain Composition PatternThese patterns implement the decisions derived from the DEIP pipeline inside real integration platforms (for example, SAP API Management, SAP Cloud Integration, Event Mesh, IoT brokers, service meshes and identity providers). The semantic control plane decides what should happen and where; the runtime patterns execute those decisions.The core principle behind all of this remains intentionally simple and universal:every integration decision starts from a single primary key — the intent of the domain.DEIP and DDCR — A Simple Mathematical ModelAlthough DEIP is primarily an architectural decision model, its pipeline can also be expressed as a simple mathematical function that transforms domain intent into a concrete integration implementation.Friends from SAP, I’m going to present the mathematical formulas that I derived. But don’t worry — the solution is DEIP itself. The formulas are only here as a visual aid to help understand the model.What matters is the architectural, structural and execution vision behind it. At this point, the way I see integration architecture is very simple: I see patterns, domains and mathematics.Mathematics is universal – 2 + 2 = 4 anywhere in the world.Look at the table below for example. The Order to Cash process is essentially the same anywhere in the world.So how does DEIP interpret this?No matter where you are in the world, regardless of language or platform, the entry point for any Order to Cash call is:/<domain>/<entity>/<action>/<target>Example:/sales/order/createWhat does this mean inside SAP API Management ?Only one proxy is required. It can be defined using a single OpenAPI or Swagger specification with an entry point like: /sales/orders/create/<target>The routing is static, and a JavaScript policy (DDCR) resolves the final destination.This means you can place 20 vendors behind a single API proxy in SAP API Management.The code can include custom headers for tracking, and additional headers can also be added if needed.This approach eliminates proxy sprawl at the root.That is the idea behind DDCR.In practice, the DDCR runtime proved this approach works. A simple JavaScript policy implementation processed around 2,067,904 requests across 8 platforms and 5 programming languages, running continuously for about 29 hours, withzero routing failures — 158 network-layer failures only (ECONNRESET/ETIMEDOUT)The full implementation details, experiments and runtime evidence are available in the GitHub repository associated with this work. DEIP(Intent, Context) → Implementation The DEIP pipeline is a sequence of deterministic functions. Each stage is a formal reduction where context constrains the valid outputs: f₁ : I × C → T
Intent + Context → Interaction Type
f₂ : I × T × C → Q
Intent + Interaction Type + Context → Quality Profile
f₃ : I × T × Q → Cap
Intent + Interaction Type + Quality Profile → Integration Capability
f₄ : Cap → Pprot
Integration Capability → Protocol Profile
f₅ : Pprot × C → Pplat
Protocol Profile + Context → Platform Binding In this model: I = Domain Intent
C = Context (environment, constraints, policies)
T = Interaction Type
Q = Quality Profile
Cap = Integration Capability
Pprot = Protocol Profile
Pplat = Platform Binding DDCR Resolution Model – Remember in SAP APIM it’s just the javascript policy the name is my creation just it.Once the decision pipeline produces a platform binding, the DDCR engine resolves the final runtime configuration using deterministic key resolution. { f(key) → value } Where the key represents the resolved integration identity derived from the DEIP pipeline, and the value represents the runtime configuration to be applied (routing target, protocol adapter, credentials, endpoint, or orchestration behavior).Applying DEIP in PracticeOnce the DEIP decision pipeline is defined, the next step is applying its outcomes inside the runtime architecture.DEIP itself does not execute integrations.Instead, it acts as a semantic control plane that guides how runtime components should behave.In practice, the pipeline outputs are implemented through the SDIA architecture and its execution patterns.DEIP → SDIAThe first layer where DEIP becomes operational is SDIA (Semantic Domain Integration Architecture).SDIA represents the runtime architecture organized by domain, where integrations are grouped and governed according to their domain intent.Instead of organizing integration artifacts by systems or projects, SDIA structures them by domains, such as: Orders
Payments
Customers
Logistics
Notifications Each domain becomes a semantic boundary where integration decisions derived from the DEIP pipeline are applied consistently.SDIA → GDCRAt the gateway layer, DEIP decisions guide GDCR (Gateway Domain-Centric Routing).GDCR is responsible for routing requests according to the domain intent.Instead of routing based only on technical endpoints, GDCR uses the domain structure to determine where requests should flow.Example: /<domain>/<entity>/<action>/<target | sender>
/sales/orders/create/salesforce
/hr/customers/update/workday
/finance/payments/authorize/stripe
/iot/sensors/stream/mqtt
/iot/devices/command/firmware Here the domain is the primary routing key.Entao com essa organizacao o que é feito dentro do SAP APIM ? Que na minha opniao é a melhor ferramenta no quisito User Design e configuracao de rotas estativas ? Vou te explicar. Proxy Sprawl (1 proxy por backend or Contract)
/sap-s4hana/orders/create
/salesforce-crm/orders/create
/oracle-erp/orders/create
/legacy-system/orders/create
↑ 4 proxies · 4 contracts · 4 versioning After with DEIP + SDIA + GDCR and DDCR GDCR (1 proxy por domínio)
/sales/<entity>/<action>/<vendor>
↑ 1 proxy · 1 contract · new vendor via metadata – KVM for SAP APIM For example – Domain: SALES – Process O2C, the same sample works for SALES – Lead to Opportunity (L2O) – Opportunity to Quote (O2Q) – Quote to Order (Q2O) etc…So you create one proxy – gdcr-proxy-domain-sales-o2c, it means what ever application, vendor, client, modile etc that goes for the intent domain SALES for APIM always will use only the entry dor /sales/ but than how to routing this ?Static routing over the entity for the HTTP path /sales/orders… /sales/customers…/sales/invoices…/sales/princingEntry door: https://<apim>/282cc9datrial/sales/ What does this configuration mean?This is a static routing rule condition in the API Proxy design. This single proxy — SALES O2C — supports all calls from anywhere, covering 13 business processes from the O2C domain.What does this still mean ?500 applications · 1 proxy · 13 routing rules = End of proxy sprawl. The rest DDCR — JavaScript — resolves alone. Don’t worry.Why did I decide to segregate the proxy per business domain? To avoid the sprawl of a single proxy responsible for all calls. This segregation also keeps everything more organized.Does DDCR work with OpenAPI and Swagger ? Yes — the JavaScript is the routing engine. There is no connection with the contract or SLA of the specification. But the mindset must change: you don’t create a specification per vendor — you create a specification per domain.This means the specification, proxy, and DDCR JavaScript are immutable. If anything new comes to onboard — add one string in the KVM. That’s it. As simple as 2+2=4. This is mathematics.But my company is working with IOT etc… so follow the same process, create proxy, add the routing, what will be the domain /LLM/ thats itgdcr-ai-llm-proxy-domain-unified https://<apim>/282cc9datrial/llmSDIA → DDCROnce a request enters the domain structure, DDCR (Domain Driven Centric Router) resolves the final integration configuration.DDCR acts as a deterministic resolution engine.It takes the resolved domain identity and looks up the metadata produced by the DEIP pipeline to determine:protocol – httpendpoint – any destinyConceptually: Domain + Intent → Configuration So let’s check again what was discussed above we are speaking about SALES – O2C means the entry door for SAP APIM:Entry door: https://<apim>/282cc9datrial/sales/ Than we have this cenario – 1 proxy – routing ( /orders/** – / customers/** – /deliveries/** 😞 https://<sapapim>/sales/orders/create/salesforce
https://<sapapim>/sales/orders/update/salesforceemea
https://<sapapim>/sales/orders/create/microsoft
https://<sapapim>/sales/customers/sync/s4hana
https://<sapapim>/sales/customers/sync/shopify
https://<sapapim>/sales/deliveries/transfer/fedex DDCR Keys — KVM (determinísticas e machine-computed) dcrporderscid01salesforce:http
dcrporderscid02sfemea:http
dcrporderscid03microsoft:http
dcrpcustomerssid04s4hana:cxf
dcrpcustomerssid05shopify:http
dcrpdeliveriestid06fedex:http Resolved URLs — CPI (execution-ready) https://<cpi>/http/dcrp/orders/c/id01
https://<cpi>/http/dcrp/orders/u/id02
https://<cpi>/http/dcrp/orders/c/id03
https://<cpi>/cxf/dcrp/customers/s/id04
https://<cpi>/http/dcrp/customers/s/id05
https://<cpi>/http/dcrp/deliveries/t/id06 Again — this logic is pure mathematics. The only way to fail is a wrong intent HTTP path or a wrong string in the KVM, that triggers in the 3rd step the FAST-FAIL M2M in ~0.1ms, the backend don’t even know about this call. It never fails. Over 2 million calls across 5 different API platforms from the market — and everything else I tested — zero routing failures.SDIA → ODCPSome integrations require orchestration across multiple domains. This is where ODCP — Orchestration Domain-Centric Pattern — operates.ODCP governs three things simultaneously:1. Package Topology — One Domain, One Package Before: After:
Salesforce_Orders_Pkg → nx.sales.o2c.integrations
SAP_S4HANA_Orders_Pkg → (same package — Sales domain)
SAP_ECC_FI_AR_v2_Package → nx.finance.r2r.integrations
FedEx_Shipping_Integration → nx.logistics.le.integrations
Ariba_Procurement_Pkg → nx.procurement.s2p.integrations
Temp_QA_DoNotDelete → eliminated 39 packages → 4. Package count becomes invariant — it scales with domains, not vendors.ODCP defines a structured package naming convention that encodes domain identity, business process, and platform context into a single readable string:ComponentDescriptionExample ValuesConstraintsprefixOrganization or platform identifiernx, sap, az, aws, muleLowercase, alphanumericdomainBusiness domainsales, finance, logistics, procurement, hr, manufacturingLowercase, no spacesprocessPrimary business process subdomaino2c, r2r, le, s2p, h2r, p2pStandard process codesintegrationsFixed suffixintegrationsAlways literal ‘integrations'[prefix].[domain].[process].integrations Multi-division — same domain, same business process, one division owns the integration:[prefix-company].[division].[domain].[businessprocess].[integration]Multi-division — same orchestration tenant, multiple divisions, same domain:[prefix-company].[division].[core].[domain]2. iFlow DNA — Deterministic Artifact Naming POST /sales/orders/create/salesforce
→ id01.o2c.salesforce.order.s4hana.c.in.sync
POST /finance/invoices/create/s4hana
→ id13.r2r.s4hana.invoice.target.c.in.sync Every artifact is traceable from semantic URL → DDCR key → iFlow DNA. No more Salesforce_Order_Sync_v3_FINAL_USE_THIS.id[seq].[subdomain].[sender].[entity].[receiver].[action].[direction].[sync|async]Example: id01.o2c.salesforce.order.s4hana.c.in.sync iFlow DNA Component ReferenceComponentDescriptionExample ValuesConstraintsRoleid[seq]Sequential flow identifier within the packageid01, id02, id99Pattern idd{2}Links to DDCR KVM iflowidsubdomainBusiness process codeo2c, r2r, le, s2pStandard process codesProcess contextsenderSource system or vendorsalesforce, sap, workday, shopifyLowercase, alphanumericIntegration sourceentityBusiness entity being processedorder, invoice, customer, shipmentLowercase, singularBusiness objectreceiverTarget backend systems4hana, oracle, stripe, targetLowercase, alphanumericIntegration targetactionCanonical action codec, r, u, d, s, n, a, tSingle character — DDCR codesOperation typedirectionMessage flow directionin, outLowercaseFlow directionsync|asyncExecution modesync, asyncLowercaseProcessing mode iFlow DNA — Implementation ProofsSemantic AddressiFlow DNAPOST /sales/orders/create/salesforceid01.o2c.salesforce.order.s4hana.c.in.syncGET /finance/invoices/get/s4hanaid10.r2r.s4hana.invoice.target.r.in.syncPOST /finance/invoices/create/s4hanaid13.r2r.s4hana.invoice.target.c.in.syncPUT /sales/customers/update/salesforceusid02.o2c.salesforce.customer.s4hana.u.in.syncPOST /logistics/shipments/sync/microsoftid21.le.microsoft.shipment.s4hana.s.in.asyncPOST /procurement/requisitions/create/aribaid31.s2p.ariba.requisition.s4hana.c.in.syncPUT /procurement/contracts/update/workdayid35.s2p.workday.contract.s4hana.u.in.syncPOST /finance/journals/post/s4hanaid14.r2r.s4hana.journal.target.a.in.syncEach iFlow DNA name is directly traceable to its semantic address in the GDCR facade and its KVM routing key in the DDCR engine. The id[seq] component is the explicit link: id01 in the iFlow DNA corresponds to iflowid id01 in the KVM key dcrporderscsalesforceid01:http.4.5 The Semantic Chain — End-to-End TraceabilitySemantic AddressDDCR KVM KeyDDCR Resolved PathODCP iFlow DNAPOST /sales/orders/create/salesforcedcrporderscsalesforceid01:http/http/dcrp/orders/c/salesforce/id01id01.o2c.salesforce.order.s4hana.c.in.syncPOST /finance/invoices/create/s4hanadcrpinvoicescs4hanaid13:cxf/cxf/dcrp/invoices/c/s4hana/id13id13.r2r.s4hana.invoice.target.c.in.syncPUT /sales/customers/update/salesforceusdcrpcustomersu salesforceusid02:http/http/dcrp/customers/u/salesforceus/id02id02.o2c.salesforce.customer.s4hana.u.in.syncPOST /procurement/requisitions/create/aribadcrprequisitions cariba id31:cxf/cxf/dcrp/requisitions/c/ariba/id31id31.s2p.ariba.requisition.s4hana.c.in.syncBusiness intent enters at the semantic address. Metadata decides at the DDCR engine. Domain governs at the ODCP orchestration layer. Technology becomes background. Semantics become the integration language — end to end.3. Credential Segmentation — Sub-Domain Tiered cr.sales.orders.rw — Orders only · 30 days rotation
cr.sales.analytics.ro — Analytics only · 90 days rotation
cr.finance.ap.rw — Accounts Payable only · 30 days rotation 39 credentials → 12. One rotation failure affects only one sub-domain — never the entire landscape.The result: Business intent enters at the semantic URL. DDCR resolves. ODCP governs the artifact. Technology becomes background.Credential Naming ConventionTechnical user names follow the same domain‑centric semantic pattern as packages and flows:Examples:cr.sales.orders.rw – Sales / Orders / Read‑Writecr.finance.ap.rw – Finance / Accounts Payable / Read‑Writecr.finance.reporting.ro – Finance / Reporting / Read‑Onlycr.logistics.shipments.rw – Logistics / Shipments / Read‑WriteThe naming convention makes credential ownership, scope, and permission level immediately readable from the identifier, eliminating the opacity of names like iflow_cred_12 or api_user_SF_orders.Three Pillars of ODCP Credential GovernancePillarPrincipleOutcomeConsolidationGroup flows by domain sub-domain, not by project or vendorEliminates credential silos and naming chaosStandardizationEnforce consistent naming: prefix.domain.subdomain.permissionEnables systematic credential audit and rotationGovernanceAssign ownership by sub-domain architect; enforce RBAC on credential mutationCentralized control, isolated blast radius, audit-readySAP-Specific Artifact ScopeIn SAP BTP Cloud Integration, the iFlow DNA naming convention extends to all integration artifacts within the package — not only iFlows. Script collections, value mappings, message mappings, data stores, communication channels, technical users, and even internal variables adopt the same domain‑centric prefixing (for example, vm.sales.order.status, sc.sales.order.transformation, cr.sales.orders.rw). This makes the entire CPI artifact space navigable by business domain rather than by technical type or vendor.Artifact TypeNaming ConventionIntegration Flows (iFlows)id[seq].[subdomain].[sender].[entity].[receiver].[action].[direction].[mode]Value Mapping Tablesvm.[domain].[entity].[field] — e.g. vm.sales.order.statusScript Collectionssc.[domain].[function] — e.g. sc.sales.order.transformationMessage Mappingsmm.[domain].[entity].[sender].[receiver] — e.g. mm.sales.order.sfdc.s4hTechnical Userscr.[domain].[subdomain].[permission] — e.g. cr.sales.orders.rwInternal Variablesvar.[domain].[context].[name] — e.g. var.sales.orders.batchsizeSDIA — COMPLETE ARCHITECTUREEnd-to-End Semantic FlowThe Semantic Domain Integration Architecture (SDIA) preserves business domain semantics across every layer of the enterprise integration stack. ODCP is the final governance layer in this chain — ensuring that semantic continuity extends from the API consumer address to the backend execution artifact.Human Semantic AddressPOST /sales/orders/create/salesforceGDCRGateway LayerSemantic gateway facade — domain-centric API governanceSingle proxy per domain · semantic URL abstraction · fail-fast enforcementDDCRResolution EngineDeterministic 7-stage runtime resolution — metadata-driven backend bindingdcrporderscsalesforceid01:http → /http/dcrp/orders/c/salesforce/id01ODCPOrchestration LayerDomain-centric package topology — iFlow DNA — tiered credential governancenx.sales.o2c.integrations · id01.o2c.salesforce.order.s4hana.c.in.syncEnterprise SystemsSAP S/4HANA · Salesforce · Oracle · Workday · Stripe · Legacy Systems · Cloud PlatformsThe ResultWhen combined, these layers create a complete architecture: DEIP — Semantic Control Plane → What · Why · Which
↓
SDIA — Domain Runtime Architecture → Organized by domain intent
↓
GDCR — Gateway Layer → 1 proxy per domain · immutable
↓
DDCR — Resolution Engine → f(key) → value · zero failures
↓
ODCP — Orchestration Layer → 1 package · DNA naming · tiered credentials
↓
Execution Platforms → SAP · AWS · Azure · Kong · IoT · AI/LLM
↓
Result = Sales + Sales + Sales + Sales The full end-to-end — based on the intention of the Sales domain. The technology does not matter. What matters is what the domain needs.ConclusionEvery enterprise integration landscape on Earth converges to the same six failure modes. Not because of bad engineers. Not because of bad platforms. Because the organizing principle was always wrong.Technology was never the primary key. The domain always was.DEIP does not add a new tool to your stack. It changes the question you ask before you build anything:What is the domain intent of this integration?Answer that first. Everything else — protocol, platform, proxy, credential, artifact — becomes a consequence.The domain never lies. It never has. We just forgot to ask it first.Start Here — Reading Order⚠️Before reading anything else — start with GDCR.GDCR is where everything began. Originally developed as DCRP and PDCP — two SAP-specific patterns — it evolved into the foundation of the entire SDIA ecosystem. Without reading GDCR first, the other documents will not make sense. This is not a suggestion. It is a requirement.Reading order:🔗GDCR — DOI: 10.5281/zenodo.18582492 ← Start here🔗DDCR — DOI: 10.5281/zenodo.18864832🔗ODCP — DOI: 10.5281/zenodo.18876594🔗SDIA — DOI: 10.5281/zenodo.18877635🔗DEIP — DOI: 10.5281/zenodo.19004802 ← This document5 Architecture Discussion SlotsI am offering five free 1:1 sessions for senior architects and integration experts who have read the documents and want to discuss the architecture at a structural and abstract level.I am not excluding any professional from the APIM or CPI space — but I want to be clear: these sessions are not about how to configure APIM routing or how to get the DDCR JavaScript running. The documents cover that.What I want to discuss is DEIP — the decision pipeline, the semantic control plane, and the structural model behind it. If that is the conversation you want to have, send me an email.This is not a course. This is not training. The documents are already published and available for free.If you have read the material and want to discuss architecture — send me an email: rhviana@gmail.comWhat comes nextIn approximately two months I will release a companion document covering how to build the complete DEIP integration map and navigate all four architectural layers in practice. I cannot commit to an exact date yet.After that — my focus moves to IEEE. The mathematics behind DDCR and DEIP deserve a formal academic submission. That is where this work goes next.The domain never lies.Ricardo Luz Holanda Viana — March 2026 — Warsaw, Poland Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
