Domain-Oriented Marts/Data Products with Shared Enterprise Dimensions and Metrics

Learning outcomes

1. From “mart table” to domain data product

A domain data product is a maintained analytical output with named consumers, owner, semantics, quality/freshness expectations, access policy, lineage, and change process. The word “product” does not require a particular architecture. In AtlasMart, finance, marketing, and operations can own their delivery surfaces while the warehouse/semantic platform supplies standardized connection points.

{  "finance": {    "owner": "finance-analytics",    "shared_contracts": ["gross_revenue_usd.v1", "fact_sales"],    "domain_outputs": ["daily revenue", "daily cost", "daily gross profit"]  },  "marketing": {    "owner": "growth-analytics",    "shared_contracts": ["gross_revenue_usd.v1", "dim_customer", "fact_sales"],    "domain_outputs": ["customer-day revenue slices", "campaign-specific extensions"]  },  "operations": {    "owner": "operations-analytics",    "shared_contracts": ["fact_sales", "dim_product", "dim_date"],    "domain_outputs": ["orders", "units", "fulfillment/stock extensions"]  }}

2. Shared core, domain-owned edge

Finance owns presentation choices for revenue/cost/profit, marketing owns campaign/audience extensions, and operations owns fulfillment/inventory extensions. They do notgross_revenue_usd.v1. This is the same enterprise-bus principle applied to team ownership: build incrementally by domain, integrate through conformed contracts.

3. Observable dependent mart outputs

Finance certified mart  revenue_usd: 820.00  cost_usd:    495.00  profit_usd:  325.00Operations certified mart  orders:      8  units:       12Marketing certified mart  revenue_usd: 820.00  customers:   5Certified wide delivery surface  rows:        10  revenue_usd: 820.00

The three domains answer different questions and therefore expose different grains. They still reconcile where they overlap: finance and marketing both see 820 USD because they consume the same governed revenue semantics. Operations can focus on 8 orders and 12 units without being forced into finance's presentation schema.

4. Consumer contract: more than columns

{  "name": "mart_finance_daily",  "owner": "finance-analytics",  "grain": "one row per order_date",  "dependencies": ["fact_sales", "gross_revenue_usd.v1"],  "freshness": "after certified daily warehouse load",  "quality": ["revenue/cost/profit reconcile to atomic facts"],  "access_class": "finance-certified",  "change_policy": "breaking changes require new contract version"}

Discoverability comes from publishing this metadata in whatever catalog the organization uses. The mechanism is independent of catalog product choice.

5. Edge case: shrinking a shared dimension

A domain does not always need every customer attribute. A marketing mart may expose only customer ID, segment, and geography. That can still be conformed if the exposed attributes preserve the same domains and meanings as the governed dimension. Copying a subset is different from remapping G-EAST to a team-local “East-ish” bucket while retaining the same column name.

6. Change propagation without blocking domain delivery

When an upstream shared metric publishes a new version, existing domain products keep their pinned version until migration acceptance passes. Domain-only attributes can evolve on the domain cadence. This separates coordination where semantics are shared from autonomy where they are not. A dependency registry makes the blast radius queryable instead of relying on meetings and memory.

SELECT mart_nameFROM mart_dependencyWHERE upstream_object='gross_revenue_usd.v1'ORDER BY mart_name;

7. Security and ownership boundaries

Ownership means responsibility for quality, freshness, documentation, support, and change—not unrestricted privilege. Domain teams may own a certified mart while access enforcement remains centralized in the database/semantic layer. The lab's access_class is metadata only; a production system must map it to actual identities, roles/policies, export controls, and audit logs.

8. Production judgment

Domain data products are useful when team accountability improves time-to-delivery and support, but they should consume shared contracts for enterprise concepts. Correctness: cross-domain controls must reconcile. Freshness/history: products state upstream watermark/version. Idempotency: rebuilds should not duplicate facts. Observability: owner, SLA, failures, and lineage are first-class. Cost: persist only where domain query/performance/value justifies duplication. Compatibility: catalog/RLS/materialization features vary by engine. Rollback: pin previous dependency versions until new certification succeeds.

9. Bridge to Lesson 3

Domain products still need ergonomic shapes. Lesson 3 examines the temptation to flatten everything into permanent wide reporting tables and shows how to keep convenience without creating a second semantic system.

Knowledge check

Authoritative references

• Kimball Group — Enterprise Data Warehouse Bus ArchitectureIncremental domain delivery integrated through reusable conformed dimensions.
• Kimball Group — Conformed DimensionsShared descriptive domains are defined once and reused to preserve analytical consistency.
• Kimball Group — Enterprise Data Warehouse Bus MatrixBusiness-process rows and dimension columns provide a planning and conformance map.
• Kimball Group — Differences of OpinionExplains why conformed facts/dimensions matter across distributed presentation marts.

10. Lab cleanup/reset

Delete atlasmart_ch21_lab (or your configured local output directory) and rerun python ch21_lab.py to recreate a clean deterministic state. No cloud resource or repository file is modified by the lab.