Gateway Domain-Centric Routing (GDCR): A Vendor-Agnostic Metadata-Driven Architecture for Enterprise API Governance — v8.0 - FINAL

GDCR — Gateway Domain-Centric RoutingLayer 1 of the SDIA Ecosystem GDCR is the semantic gateway layer of SDIA (Semantic Domain Integration Architecture). Its role is not to own orchestration or backend logic, but to govern the API facade: the Semantic URL, the Proxy DNA, and the Metadata Container DNA. In GDCR, the domain becomes the primary key of the gateway surface. Consumers interact with stable semantic paths organized by business intent, while backend volatility is externalized to metadata. The result is a domain-scoped facade that remains structurally stable even as vendors, systems, and routes evolve behind it. The proxy becomes immutable because the routing intelligence is not hardcoded into the proxy artifact itself. Immutability is achieved by the DDCR runtime logic operating as a policy, script, filter, or plugin behind the facade. GDCR governs the facade contract; DDCR governs the downstream deterministic resolution that keeps that facade unchanged. The Essentials in 7 Lines 1. Create one proxy per domain — e.g., /sales/*, /finance/*2. Use optional subdomains when useful — e.g., /sales/o2c/orders3. Store route mappings in metadata — e.g., KVM, Redis, DynamoDB, HashMap4. Let DDCR resolve the semantic request deterministically at runtime5. Keep the proxy artifact unchanged6. Add or replace vendors through metadata entries only7. Run the proxy — every operational change becomes metadata, not proxy redevelopment Why it works Immutable facadeThe consumer-facing proxy is created once and kept structurally stable. Mutable control planeNew backend, new vendor, or new route = metadata update only. Deterministic DDCR runtimeResolution is executed by a deterministic runtime layer that interprets the semantic request and resolves the backend target from registered metadata only. Portable implementation modelThe same logic has been exercised in multiple technical forms: JavaScript, Java, C#, Python, Lua, and plugin/filter-style implementations. The principle is not tied to a single vendor runtime and can be implemented on other gateway technologies when needed. What GDCR is Gateway Domain-Centric Routing (GDCR) is a vendor-neutral, technology-agnostic governance model for enterprise API gateways. Instead of indexing APIs by backend system, environment, or vendor product, GDCR indexes the facade by business domain semantics. Traditional gateway landscapes multiply proxies because every backend change tends to create a new externally visible artifact. GDCR replaces that pattern with one proxy per domain, semantic URLs, and metadata-driven backend variability. The external contract stays stable; the technical target changes behind the facade. What makes the proxy immutable The proxy is not immutable by itself. It remains immutable because DDCR executes the routing logic behind it. DDCR (Domain Driven-Centric Router) is the deterministic runtime resolution layer used downstream of GDCR. It can be implemented as a gateway policy, script, filter, function, or plugin depending on platform capabilities. In validated implementations, DDCR was exercised across multiple runtimes and languages, including JavaScript, Java, C#, Python, and Lua. The architectural principle remains portable to other equivalent gateway extension models. This is the critical separation: - GDCR = semantic gateway facade- DDCR = deterministic runtime resolution layer- Metadata = mutable control plane- Proxy artifact = stable data plane Position inside SDIA GDCR is Layer 1 of SDIA. Layer 1 — GDCRSemantic gateway contractOne proxy per domainSemantic URLsFacade governanceMetadata container naming Layer 2 — DDCRDeterministic runtime resolutionAction normalizationRouting-key constructionMetadata lookupFail-fast execution Layer 3+ Companion layersODCP — orchestrationEDCP — eventsDDCP — dataDEIP / SDIA — ecosystem and decision model GDCR does not replace the rest of the architecture. It defines the gateway facade and the semantic entry point of the stack. Validated implementation model The underlying routing principle was validated across multiple gateway and runtime forms. The logic proved portable across policy-based and plugin-based implementations, using different metadata stores and runtime technologies. Validated technical forms include: - JavaScript policy/script runtime https://github.com/rhviana/deip/blob/main/src/javascript/js-codes/dcrp-js-phantomv12.js - Java filter/runtime implementation https://github.com/rhviana/deip/tree/main/src/java-zuul - C# policy/runtime implementation https://github.com/rhviana/deip/tree/main/gdcr-proven/gdcr-microsoft-azure-api - Python function/runtime implementation https://github.com/rhviana/deip/tree/main/gdcr-proven/gdcr-aws-api - Lua plugin/runtime implementation https://github.com/rhviana/deip/tree/main/src/handlers Validated gateway and execution environments include major enterprise gateway patterns such as SAP API Management, Kong Gateway, AWS API Gateway, Azure API Management, Netflix Zuul, and equivalent portable models. The architecture is therefore platform-neutral in principle and implementation-portable in practice. Scope boundary This work validates GDCR primarily as an enterprise-owned semantic facade with metadata-driven backend variability. It is strongest where the enterprise owns the external semantic contract and needs stable domain-level governance, backend substitutability, and zero-redeployment onboarding. Direct consumption of vendor-standard ERP APIs (for example SAP ERP / S/4HANA OData or SOAP APIs, Workday APIs, and similar packaged vendor surfaces) was not the primary validated scope without intermediate orchestration. In such cases, the architectural principle still holds, but the trade-off changes because the backend contract is already vendor-standardized. Simple orientation GDCR means the enterprise should be understandable from the outside by meaning, not by hidden internal structure. A hospital is reached through cardiology, emergency, or pediatrics — not building codes and cable paths.An airport is reached through departures, arrivals, or baggage claim — not internal operational topology.A university is reached through admissions, library, or finance — not whichever office moved last quarter. That is the role of GDCR at the gateway layer: the outside is organized by semantic domain intent, while the inside remains technically flexible. Composition of GDCR Domain structureMajor business areas such as sales, finance, logistics, procurement Semantic facadeStable consumer-facing semantic entry points Governance boundariesClear domain ownership, policy boundaries, naming consistency Metadata control planePortable representation of backend variability and routing targets DDCR runtime layerThe deterministic execution component that makes the facade operational without changing the proxy Research position GDCR is not a gateway product and not a vendor feature. It is a semantic governance model for the API gateway layer. Its contribution is to make the business domain the stable organizing principle of the facade while moving technical variability into a controlled metadata plane executed by a deterministic runtime layer. The domain never lies. LinksRepository: github.com/rhviana/deipDEIP Ecosystem: 10.5281/zenodo.19004802ORCID: 0009-0009-9549-5862 AuthorRicardo Luz Holanda VianaIndependent Solo Researcher | Enterprise Integration ArchitectSAP BTP Integration Suite Expert | SAP Press e-Bite Author — Enterprise Messaging (2021) CitationViana, R. L. H. (2026). Gateway Domain-Centric Routing (GDCR) — Version 8.0. Zenodo. https://doi.org/10.5281/zenodo.18582492