PUBLIC REFERENCE RELEASE
Architecture published under CC BY 4.0. Interactive wizards are public beta.
DEIP v3.0 - Final · 2026
The Domain Never Lies.
DEIP is a semantic control plane for enterprise integration — a governance model where domain intent is the only valid primary key across every layer of your architecture.
"Technology is transient. The domain never lies."
DEIP Architecture Overview
DEIP — Semantic Control Plane
⬡ THE DOMAIN LAYER
└── SDIA— Runtime Architecture
├── GDCR— Gateway Layer
├── DDCR— Resolution Engine
├── ODCP— Orchestration Layer
├── EDCP— Event Layer
└── DDCP— Data Layer (WIP)
⬡ THE EXECUTION LAYER
└── SAP · AWS · Azure · GCP · Kong · MuleSoft · Kafka · Salesforce · ServiceNow · Solace · Workday · IoT · AI/LLM · & other vendors
2,067,904
Requests validated with DDCR
100%
Routing resolution
5
Architecture layers
The Problem
Integration chaos is a naming problem in disguise.
In most enterprise landscapes, integration artifacts are named after the platform that runs them — not the business intent behind them. The result is a fragile, unmaintainable sprawl that breaks the moment a vendor changes or an engineer leaves.
❌ Technology-first — Same Landscape
SAP BTP Integration Suite + Mulesoft + Boomi ???
SAP AEM + Solace + Kafka + RabbitMQ ???
SAP APIM + Mulesoft APIM + Azure APIM ???
REST + SOAP + OData + GraphQL (same domain, no reason) ???
cr_global_rw (shared by 39 flows, 4 domains) ???
iflow_Microsoft_Orders_SAP_sync_Outbound
iflow_Orders_v2_FINAL_fixed_PROD
JMS Queue: Orders (used by 3 iFlows ???)
Owner: "the integration team"
Owner: someone from project X (left the company)
Docs: See old SharePoint (link broken)
Credential rotation: last done Q3 2022 (maybe)
sales.o2c.orders.create.v1 → deprecated
sales.o2c.orders.create.v2 → active
Owner: Sales Domain Architect
Docs: deterministic by name — no SharePoint required
🔴
Vendor sprawlMultiple platforms running in the same landscape with no governance model. Every new vendor adds a new naming convention, a new config artifact, and a new operational silo.
🔴
Knowledge locked in namesWhen the developer who named the artifact leaves, nobody knows what it does, which domain it belongs to, or who is responsible for it.
🔴
Platform couplingArtifacts tied to SAP, MuleSoft, or Kafka by name cannot survive platform migrations without a full rename, re-documentation, and re-governance effort.
🔴
Artifact SprawlPackages multiply per project. Credentials accumulate per integration.
Value mappings, scripts, and data stores are named ad hoc. Multiple protocols
serve the same domain capability. Each layer sprawls independently — no shared
organizing key, no lineage, no reuse.The platform is. And the platform changes.
🟢
DEIP / SDIA approachDomain intent as the only primary key. The platform is an implementation
detail. The name encodes the business capability — not the technology that
delivers it. When the platform changes, the semantic address does not. When the
vendor is replaced, the consumer never knows. When a new architect joins, the
artifact landscape explains itself.
Architecture Transformation
From Frankenstein landscape to domain governance.
Most enterprise integration landscapes grow organically — by project, by vendor, by whoever was on call. DEIP replaces that sprawl with a single primary key: domain intent.
Integration governance model
Swipe horizontally on mobile to inspect the full diagram.
What is DEIP
A semantic control plane for enterprise integration.
DEIP — Domain Enterprise Integration Pattern — is a vendor-neutral architectural governance model created in 2026. It defines how domain intent flows through every layer of an enterprise integration landscape.
DEIP Decision Pipeline
1
Intent
What does the business need to do?
2
Interaction Type
Sync, Async, Event, Batch, Stream?
3
Quality Profile
Latency, reliability, consistency requirements
4
Integration Capability
Which pattern? GDCR, ODCP, EDCP…
5
Protocol Profile
REST, gRPC, AMQP, MQTT, SOAP, JDBC…
6
Platform Binding
SAP · AWS · Azure · Kong · Kafka · IoT
DEIP does not replace your integration platform. It governs how you think about and name everything that runs on it. The platform is the last decision — not the first.
The model crystallized from two SAP-oriented routing patterns into a five-layer semantic architecture. First documented in 2026 during a late-night architecture review in Warsaw, Poland.
"Everything begins with a single primary key: the intent of the domain. The domain never lies."
The runtime implementation of DEIP is SDIA — Semantic Domain Integration Architecture — a five-layer reference architecture that maps each governance decision to a concrete runtime layer.
SDIA is the runtime governance layer of DEIP. Each pillar governs a specific layer of the ecosystem — all indexed by domain intent, never by technology.
SDIA architecture layers — click a pillar to explore
Two hands-on simulators — one to validate your integration decision using DEIP, one to generate domain-governed naming using SDIA.
🧠
Simulation DEIP
Decision Engine · Pattern Resolver
Describe your business integration scenario. DEIP analyses the domain intent, interaction type, and quality profile — then resolves the correct integration pattern and layer binding.
Enter your domain, subdomain, entity and action. SDIA generates the complete naming convention across every integration object — iFlow, API route, topic, queue — all domain-governed.
GDCR and DDCR validated in Trial Accounts — cross-atlantic Newman execution Poland → US → Poland, across multiple enterprise platforms and programming languages. Stress-tested with over 2M+ requests before first publication.
2,067,904
Total requests with DDCR logic
99.99%
End-to-end success rate
100%
Routing resolution success
0
Routing failures
Site Analytics
Who is exploring DEIP?
Live visitor counter and platform distribution — updated in real time.
Enterprise Integration Architect · DDCR™ Inventor · SAP BTP Expert
Warsaw, Poland — Ricardo is an Enterprise Integration Architect specializing in SAP BTP Integration Suite and large-scale iPaaS governance. He created DEIP and SDIA in 2026 after years of observing the same anti-patterns: platform-coupled artifact naming, proxy sprawl, and institutional knowledge that disappears when engineers leave.
