Domain Mesh topology 

Federated by domain. Full autonomy, full responsibility.

​Pros

• Domain autonomy - Each domain controls its own destiny. They choose their tools, set their pace, and own their outcomes. No waiting for a central team to prioritise their requests.

• Scales with organisational structure As the business grows, new domains spin up their own workspaces. The architecture scales horizontally without bottlenecking on a central platform team.

• Clear accountability Each domain is responsible for the quality, security, and availability of their data products. Ownership is unambiguous.

• Fit-for-purpose design Different domains have different needs. Finance might need tight controls and audit trails; Marketing might need speed and experimentation. Each can optimise their topology accordingly.

• Resilience through independence A problem in one domain doesn't cascade to others. If Sales has a pipeline failure, Finance keeps running.

​

Cons​​

• Global organisations with regional autonomy EMEA, APAC, and Americas each operate their own data platform. They share global reference data but build regional analytics independently.

• Governance complexity With multiple domains operating independently, maintaining consistent standards (naming, security, quality) requires deliberate effort. Without governance, you get chaos.

• Cross-domain reporting is hard Building a report that spans Finance, Sales, and Marketing data requires shortcuts across multiple domains, alignment on schemas, and coordination on refresh timing.

• Duplication risk Without visibility, two domains might build similar pipelines or semantic models independently. You lose the efficiency of shared assets.

• Skills distribution Each domain needs people who understand data engineering, not just analytics. If a domain lacks engineering capability, they struggle.

• Discovery challenges Finding what data exists across the organisation becomes harder. You need a data catalogue or similar mechanism to make domain assets discoverable.

Example Scenarios

• Large enterprise with distinct business units A conglomerate where Finance, HR, Supply Chain, and Sales operate as semi-independent units. Each has its own budget, its own priorities, and its own data team. Centralising would create more friction than value.

• Data mesh adoption The organisation has committed to data mesh principles: domain ownership, data as a product, self-serve infrastructure. The Domain Mesh topology is the natural Fabric implementation.

• Acquisitions or mergers You've acquired a company with its own data stack. Rather than force immediate integration, you let them operate as a separate domain while gradually aligning standards.

• Regulated multi-entity structures A financial services group with separate legal entities. Each entity needs its own workspace boundary for compliance, but they still share certain reference data.

When This Topology Breaks Down

• The organisation is too small to justify the overhead (under 50 people working with data)

• Cross-domain use cases dominate (most reports need data from multiple domains)

• Domains lack the skills or budget to run their own engineering

• There's no governance framework to ensure consistency across domains

• If cross-domain integration is your primary use case, consider whether a Hub and Spoke with shared ownership would serve you better.

Considerations

• Establish governance standards early Define naming conventions, security baselines, data quality expectations, and documentation requirements that all domains must follow. Without these, the mesh becomes a mess.

• Invest in a data catalogue When data is distributed, discovery becomes critical. Implement a catalogue (Purview or similar) so people can find what exists across domains.

• Define data product contracts Each domain that exposes data to others should document what they provide: tables, refresh cadence, schema stability, support model. Consumers should know what they can rely on.

• Create cross-domain forums Regular syncs between domain leads help surface duplication, share patterns, and align on standards. Autonomy doesn't mean isolation.

• Plan for cross-domain reporting Decide upfront how you'll handle reports that need data from multiple domains. Options include: a dedicated cross-domain workspace, a shared semantic model layer, or domain-specific shortcuts into a reporting workspace.

• Monitor at the tenant level Individual domain monitoring isn't enough. You need tenant-wide visibility into capacity consumption, security events, and compliance status.