Data Product Boundaries
Summary
Data product boundaries are the reusable explanation for how source data moves from ingestion to canonical entities, gold facts, serving snapshots, and UI or review surfaces. Domain threads should link here instead of re-explaining why a UI should not directly own analytics joins or why pipelines should publish rather than mutate interactive state.
Reader Question
Which layer owns source shape, canonical truth, operational facts, serving state, and interactive repair state?
Surface Or Workflow
The reader usually starts from stale or surprising UI data. The answer should point to a data product, publish step, read model, or serving snapshot, not to a route-local query across raw warehouse tables.
Lifecycle
External sources seed lakehouse tables. Bronze preserves source shape. Silver canonicalizes customers, jobs, locations, prospects, vendors, technicians, and crosswalks. Gold publishes operational facts such as prospect flags, marketing facts, morning brief facts, and other rollups. Serving snapshots and read models make those facts stable for API and UI use.
Interactive state remains separate: cases, issues, approvals, repairs, and operator decisions belong in OLTP-style workflow state, not in rebuildable analytics transforms.
Child Threads
- One Database Many Responsibilities: conceptual separation before physical split.
- Lakehouse Service Boundary: service access to lakehouse behavior.
- Explicit Publish Steps: how data becomes serving state.
- Serving Snapshots: stable UI-facing projections.
- Freshness And Data Ready Checks: when workflows may safely use data.
Implementation Boundaries
Lakehouse service behavior lives under services/lkci_lakehouse; transforms under pipelines/lakehouse; repeatable job entrypoints under jobs/lakehouse; sync linkage under services/data_sync; tests under tests/lakehouse, tests/pipelines, and related domain suites.
Tradeoffs
Explicit data products require more publishing discipline than direct queries. That discipline is what keeps interactive repair surfaces independent from rebuildable analytics state and makes future database separation practical.
Visual
The current visual is a graph neighborhood. The intended visual is a lineage diagram from source system to bronze, silver, gold, publish step, serving snapshot, UI read model, and workflow state.
Source Evidence
docs/reference/architecture.mddocs/domains/lakehouse.mddocs/domains/data_sync.mdservices/lkci_lakehousepipelines/lakehousejobs/lakehouseservices/data_synctests/lakehousetests/pipelines