DEIP — Domain Enterprise Integration Pattern: A Semantic Control Plane for Enterprise Integration Governance - v2.0

⚠️ Reading Order — Start with GDCR. GDCR (DOI: 10.5281/zenodo.18582492) is the foundation. Begin there. Every other layer builds on top of it. What is DEIP? Imagine your company has 10 different systems — SAP, Salesforce, Workday, Stripe, and more. Every time you need them to talk to each other, someone builds a direct connection. After a while you have hundreds of connections, nobody knows what connects to what, and changing one system breaks everything else. DEIP fixes this at the root. The idea is simple: stop organizing integrations by technology. Start organizing by business domain. Instead of asking "which system do I call?" — you ask "what is the business intent?" The 6-Step Decision Pipeline DEIP gives you a structured way to make every integration decision — once, consistently, for the entire enterprise: Step 1 — Intent: What is the business purpose? Example: sales order creation Step 2 — Interaction Type: How does it communicate? Request? Event? Batch? Stream? Step 3 — Quality Profile: What does it need? Low latency? High reliability? Audit trail? Step 4 — Integration Capability: What architectural pattern fits? API mediation? Event streaming? CDC replication? Step 5 — Protocol Profile: What transport? REST? Kafka? MQTT? SOAP? Step 6 — Platform Binding: Where does it run? SAP CPI? Kong? AWS? Azure? Same pipeline. Every integration. Every domain. Every team. What does this eliminate? Problem Before DEIP After DEIP Too many proxies 1 proxy per backend system 1 proxy per business domain Too many packages Named by vendor or project Named by domain Vendor onboarding Hours to days 30 seconds — 1 metadata entry Routing logic Hardcoded in every proxy In the metadata control plane AI agent integration Ad-hoc, ungoverned Domain-semantic, governed The Runtime — SDIA Ecosystem When DEIP makes a decision, SDIA executes it: Consumer → /sales/orders/create/salesforce └── GDCR — 1 gateway per domain └── DDCR — resolves f(key) → value in <4ms └── Execution Platform └── ODCP — governs artifacts └── DCEP — governs events └── DCBP — governs data Every layer. Same domain. Same invariant. Validated Results ~2,067,904 requests · 8 platforms · 5 languages · 100% routing accuracy · zero routing failures · sub-4ms resolution latency · 99.99% uptime The one rule that governs everything: The domain intent is the only valid primary key for integration governance. Technology is transient. The domain never lies. DOI Ecosystem GDCR v7.0: 10.5281/zenodo.18582492 ← Start here DDCR v2.0: 10.5281/zenodo.18864832 ODCP v2.0: 10.5281/zenodo.18876593 SDIA v2.0: 10.5281/zenodo.18877635 DCEP v1.0: 10.5281/zenodo.19068766 DCBP: Under active development Version History Version Status DOI v2.0 ✅ CURRENT zenodo.org/records/19004802 v1.0 ⚠️ Superseded zenodo.org/records/19004802 Links Repository: github.com/rhviana/deip DEIP (this document): https://zenodo.org/records/19004802 GDCR (Start here): https://doi.org/10.5281/zenodo.18582492 Citation (v2.0) APA: Viana, R. L. H. (2026). DEIP — Domain Enterprise Integration Pattern: A Semantic Control Plane for Enterprise Integration Governance — Version 2.0. Zenodo. https://zenodo.org/records/19004802 Author Ricardo Luz Holanda Viana Enterprise Integration Architect | Creator of DEIP Ecosystem | SAP BTP Integration Suite Expert | SAP Press Author Warsaw, Poland · March 2026 · ORCID: 0009-0009-9549-5862 "Technology changes by the quarter. Business processes last for decades. The domain never lies."