🧩 Designing Layered Data Models with Inbound, Intermediate, and Outbound Entities

A Core Design Rule in Model-Driven Data Engineering

Summary

In Model-Driven Data Engineering (MDDE), data models aren’t static diagrams — they are semantic building blocks that can be connected, versioned, validated, and automated.

Every model has its own role within the data platform, but what’s often forgotten is that models also need internal structure to remain maintainable as they evolve.

That’s where the Inbound → Intermediate → Outbound principle comes in.
It’s a simple but powerful design rule that isolates change, simplifies mappings, and makes metadata-driven automation far more robust.

💡 1. From Diagrams to Declarative Models

In model-driven engineering, every data flow is described as a connection between models. Each model defines:

• What data it receives (inbound).
• How that data is transformed (intermediate).
• What data it exposes (outbound).

Without a clear distinction between these three roles, models quickly become tightly coupled, fragile, and difficult to refactor.

A good model doesn’t just define data — it defines how data flows through it_._

🧩 2. The Three Types of Entities

Each model consists of three logical layers of entities, each serving a distinct purpose in the platform.

🔹 Inbound Entities — Controlled Entry Points

Inbound entities represent the formal input interface of a model.
All external data entering the model must go through an inbound entity.

Each inbound entity maps to a single source model, ensuring that:

• The dependency is clear and maintainable.
• Source model changes affect only one location in the dependent model.

Never connect multiple entities in a model directly to the same source model — it multiplies maintenance effort and introduces inconsistency.

Example:

model: sales
inbound_entities:
– customer_in
– order_in

Each inbound entity acts like an adapter between the source and the internal model.

🔸 Intermediate Entities — Private Transformation Steps

Intermediate entities represent the model’s internal logic.
They are where transformations, joins, aggregations, and enrichment happen.

They can combine inbound data, apply business rules, or prepare results for publishing. However, they are private to the model and should never be exposed as a mapping source for other models.

Intermediate entities are like private functions in code — essential internally, but invisible externally.

Example:

intermediate_entities:
– order_enriched
– customer_scored

🔹 Outbound Entities — The Model’s Public Interface

Outbound entities define the published output of the model.
These are the entities that downstream models may map to.

Outbound entities together form the contract between the model and its consumers — the only layer visible externally.

Only outbound entities should be used as mapping sources by dependent models.
Never expose intermediates; they are not part of your public API.

Example:

outbound_entities:
– order_summary
– customer360

⚙️ 3. The Mapping Rules

In a metadata-driven system, mappings describe how entities connect across models. To keep these mappings clean, we apply strict connection rules:

Press enter or click to view image in full size

These rules prevent tangled dependencies and make regeneration or refactoring of models safe and automatic.

🔍 4. Why This Matters — Change Isolation

A well-structured model isolates change across three dimensions:

1. When a source model changes:
   Only the inbound entity (and its mapping) needs adjustment.
   Other transformations remain untouched.
2. When internal logic changes:
   Intermediate entities can evolve freely — the inbound and outbound interfaces stay stable.
3. When consumers evolve:
   As long as outbound entities maintain compatibility, downstream models remain unaffected.

The Inbound–Intermediate–Outbound pattern turns every model into a self-contained, modular boundary of meaning — independently changeable, traceable, and testable.

🧠 5. Validation, Testing, and Automation

Because these roles are defined declaratively in metadata, validation and governance can be automated:

• Detect violations (e.g., intermediate-to-intermediate mappings between models).
• Enforce dependency rules automatically during model generation.
• Generate lineage graphs that clearly distinguish internal and external flows.
• Validate that all outbound entities are mapped downstream (and intermediates are not).

This turns your model catalog into a self-verifying metadata ecosystem.

🧩 6. Example: The Sales Domain Model

Here’s what a simple layered model looks like:

model: sales_domain
inbound_entities:
– customer_in
– order_in
intermediate_entities:
– enriched_orders
– joined_customer_orders
outbound_entities:
– order_summary
– customer_revenue

Each inbound entity maps from one source model (e.g., CRM or Orders).
🔹Intermediate entities combine and enrich data internally.
🔹Outbound entities define the model’s exposed results.

Lineage becomes clear:

CRM/Orders → Inbound → Intermediate → Outbound → Analytics

🧱 7. Interface Consistency Across Layers

This pattern scales elegantly across your entire platform.

• The Anti-Corruption Layer acts as an inbound interface model — translating from legacy systems.
• The Common Integration Layer defines the harmonized intermediate structures shared across domains.
• Downstream domains consume outbound entities as their inbound interfaces.

Each layer follows the same rules — isolation, clarity, and testability — making your platform semantically consistent from end to end.

🧾 8. Conclusion — Models as Living Contracts

When data models follow the Inbound → Intermediate → Outbound structure, they become more than just SQL or YAML — they become living contracts between layers.

Each model declares what it accepts, how it transforms, and what it delivers — all governed by metadata.

🔹Great data platforms aren’t defined by the tools they use, but by the discipline of their models.
🔹The Inbound–Intermediate–Outbound pattern makes that discipline explicit, testable, and automatable.

🧩 Metadata-Driven Architecture Series

1️⃣ Scaling Metadata-Driven Data Modeling — From Conceptual to Physical with Git and YAML
2️⃣ Generating Logical Models Automatically from Conceptual Metadata
3️⃣ The Common Integration Layer: Building a Harmonized Semantic Backbone (coming soon)
4️⃣ The Metadata-Driven Anti-Corruption Layer
5️⃣ Implementing the Anti-Corruption Layer in Practice
6️⃣ Designing Layered Data Models with Inbound, Intermediate, and Outbound Entities 👈