Home > Docs > Reference Architectures > Large Enterprise Multi-Domain

🏛️ Large Enterprise Multi-Domain Reference Architecture¶

Last Updated: 2026-05-05 | Version: 1.0.0

📑 Table of Contents¶

• 🎯 Architecture Overview
• 🏗️ Architecture Diagram
• 📦 Component Table
• 📏 Capacity Sizing Guidance
• 🔒 Network Architecture
• 💰 Cost Estimation Framework
• 🚀 Deploy This Architecture
• ⚖️ Tradeoffs and Limitations
• 📚 References

🎯 Architecture Overview¶

This architecture serves large organizations (50+ data practitioners) with multiple business domains that each own their data products. It follows Data Mesh principles: each domain (e.g., Finance, Operations, Marketing) gets its own Fabric capacity and set of workspaces with autonomous data engineering teams, while a central governance hub powered by Microsoft Purview enforces data quality, lineage, and compliance policies across all domains. CI/CD is automated through fabric-cicd, promoting Fabric items across Dev → Test → Prod stages via GitHub Actions. Network isolation through private endpoints and managed VNets ensures enterprise-grade security.

🏗️ Architecture Diagram¶

graph TB
    subgraph Governance["Central Governance"]
        PURVIEW[Microsoft Purview<br/>Data Catalog & Lineage]
        CATALOG[OneLake Catalog<br/>Discovery & Access]
        MONITOR[Workspace Monitoring<br/>Capacity Metrics]
        CICD[fabric-cicd<br/>GitHub Actions]
    end

    subgraph DomainA["Domain A — Finance (Capacity F64)"]
        subgraph A_Dev["Dev Workspace"]
            A_DEV_LH[Lakehouse Dev]
            A_DEV_NB[Notebooks Dev]
        end
        subgraph A_Prod["Prod Workspace"]
            A_BRONZE[Bronze Lakehouse]
            A_SILVER[Silver Lakehouse]
            A_GOLD[Gold Lakehouse]
            A_SEM[Semantic Model<br/>Direct Lake]
        end
        subgraph A_BI["BI Workspace"]
            A_PBI[Power BI Reports]
        end
    end

    subgraph DomainB["Domain B — Operations (Capacity F64)"]
        subgraph B_Dev["Dev Workspace"]
            B_DEV_LH[Lakehouse Dev]
        end
        subgraph B_Prod["Prod Workspace"]
            B_BRONZE[Bronze Lakehouse]
            B_SILVER[Silver Lakehouse]
            B_GOLD[Gold Lakehouse]
            B_SEM[Semantic Model<br/>Direct Lake]
        end
        subgraph B_BI["BI Workspace"]
            B_PBI[Power BI Reports]
        end
    end

    subgraph DomainC["Domain C — Marketing (Capacity F32)"]
        subgraph C_Prod["Prod Workspace"]
            C_BRONZE[Bronze Lakehouse]
            C_GOLD[Gold Lakehouse]
            C_SEM[Semantic Model]
        end
    end

    subgraph SharedServices["Shared Services (Capacity F32)"]
        SHARED_LH[Shared Reference Data<br/>Lakehouse]
        SHARED_SEM[Cross-Domain<br/>Composite Model]
    end

    subgraph Network["Network Layer"]
        PE[Private Endpoints]
        VNET[Managed VNet]
        FW[Firewall Rules]
    end

    PURVIEW --> A_Prod
    PURVIEW --> B_Prod
    PURVIEW --> C_Prod
    CATALOG --> A_GOLD
    CATALOG --> B_GOLD
    CATALOG --> C_GOLD

    CICD -->|Deploy| A_Dev
    CICD -->|Promote| A_Prod
    CICD -->|Deploy| B_Dev
    CICD -->|Promote| B_Prod

    A_GOLD -->|Shortcut| SHARED_LH
    B_GOLD -->|Shortcut| SHARED_LH
    C_GOLD -->|Shortcut| SHARED_LH
    SHARED_LH --> SHARED_SEM

    PE --> VNET
    VNET --> A_Prod
    VNET --> B_Prod
    VNET --> SharedServices

📦 Component Table¶

📏 Capacity Sizing Guidance¶

Per-Domain Capacity¶

Total Capacity Planning Example (4 Domains)¶

Key sizing principles:

• Give each domain its own capacity to prevent noisy-neighbor effects
• Small domains can share a capacity if workload profiles are compatible
• Use Workspace Monitoring to right-size after 30 days of production data
• Apply 1-year reservations to stable domains (saves ~40%)

🔒 Network Architecture¶

Enterprise deployments require defense-in-depth network isolation:

See Network Security Best Practices for detailed implementation guidance.

💰 Cost Estimation Framework¶

Cost optimization strategies:

1. Capacity reservations — 1-year commitments save ~40% on stable workloads
2. Pause dev/test capacities — Only run during business hours (saves 60%)
3. Consolidate small domains — Share capacity between low-utilization domains
4. Monitor and right-size — Use Workspace Monitoring to identify over-provisioned capacities
5. OneLake tiering — Archive cold data to reduce storage costs

🚀 Deploy This Architecture¶

Infrastructure as Code¶

Step-by-Step Tutorials¶

Key Feature Documentation¶

⚖️ Tradeoffs and Limitations¶

📚 References¶