Skip to content

PATTERN Cited by 1 source

Domain-driven data modeling choice

Intent

Empower each domain team to choose the data model shape (separate or monolithic) that best fits their specific business domain, using a shared set of considerations as a decision framework.

How it works

A central data architecture team establishes: 1. Foundational principles — non-negotiable structural rules everyone must follow 2. Decision guidelines — a shared framework of considerations (attribute commonality, future evolution, upstream alignment, downstream consumers, performance, compatibility)

Teams then apply these guidelines to their domain's specifics and make the call themselves. The result is decentralized execution within centralized guardrails (Source: sources/2026-06-09-airbnb-scaling-beyond-one-data-architecture).

When to use

  • Multi-product data architectures where one-size-fits-all doesn't work
  • Organizations with many domain teams working on different parts of the data warehouse
  • When the data landscape is too diverse for a single top-down schema decision

Trade-offs

  • Pro: Each domain gets the model shape that best fits its data
  • Pro: Teams have ownership and move faster on their domain
  • Con: Requires strong foundational principles to prevent chaos
  • Con: Cross-domain queries may be harder when some domains are separate and others monolithic

Seen in

Last updated · 542 distilled / 1,571 read