There’s a pattern I see in mature analytics organizations: as soon as the data platform gets big enough to feel “enterprise,” someone reaches for domain-driven design (DDD) as the organizing principle for data engineering and governance.
It’s an understandable move. DDD gives us language for ownership, boundaries, and “this team is responsible for that thing.” And when you’re trying to untangle a spaghetti warehouse, that sounds like oxygen.
But here’s the catch: the most valuable data in a warehouse—the fact tables in traditional star schemas—often doesn’t live neatly inside a single domain. It lives at the intersections.
In this post, I’m going to make three points:
- why domain boundaries tend to break down precisely where the business value shows up (facts)
- how a data product model handles “intersection data” without inventing reference domains and mega-joins
- why Microsoft Fabric’s workspace + lakehouse + OneLake tooling makes the product approach easier to execute in practice (especially with shortcuts, security, and materialized lake views)
And yes—domains still matter. Just not as the unit of delivery.
Continue reading “When Facts Don’t Live in a Domain: Why Data Products Beat Pure Domain-Driven Data Engineering”