The goal here is not to pick “the one right” modeling pattern. The goal is to create clarity on how raw data becomes reusable building blocks, and where the contract with consumers lives. Without that clarity, every team models differently, definitions drift, and the same logic gets rebuilt across layers and dashboards.

Start from the consumer, not the architecture diagram

Different consumers pull you toward different modeling choices.

If the primary consumer is BI and self-service analytics, you need stable facts and dimensions and a clear place where KPI logic lives. If the primary consumer is data science or AI, you may accept more flexibility in upstream layers, but you still need consistent entities, identifiers, and definitions or the outputs become unreliable.

Freshness matters too. Near real-time needs often require different trade-offs than batch reporting, and those trade-offs should be explicit.

Separate concerns with layers

Most teams do not fail because they chose the “wrong” pattern. They fail because layers get mixed, and nobody knows what each layer is allowed to contain.

A pragmatic default is a layered approach where each layer has a purpose:

• Bronze: raw, traceable ingestion so you can always explain where data came from.
• Silver: cleaning and standardization so duplicates, inconsistent formats, and missing IDs do not leak downstream.
• Gold: business modeling so reusable facts, dimensions, and shared business logic are available as a stable contract.
• Platinum (optional): tailored outputs for a specific audience or workflow when a generic gold model is not enough.

The key is that the organization agrees what belongs where, and enforces that agreement lightly but consistently.

Decide where “truth” lives

A common failure mode is letting truth live “everywhere.” When KPI logic is spread across dbt models, BI tools, and ad-hoc notebooks, drift is inevitable.

Choose a primary home for business-critical definitions. In many setups that is the gold model. In others it is a semantic layer. What matters is not the tool, but that there is one shared contract that multiple consumers can rely on.

Pick a default for the gold layer

Once you have layers and a contract, you can choose modeling patterns more calmly.

For broad analytics, a star schema is often the simplest default because it is easy to understand, performs well, and supports self-service. More complex hierarchies may justify snowflake or hybrid approaches, but complexity should earn its place.