Keeping models modular and avoiding repeated logic

Modularity in dbt means breaking transformation logic into small, reusable, single-purpose models rather than writing one large monolithic SQL file. DRY (Don't Repeat Yourself) principles are achieved by centralizing shared logic in staging models, macros, and packages so that changes only need to be made in one place.

1 · Learn the must-know

• 1Staging models should do minimal transformation (renaming, casting, light cleanup) and one staging model per source table, so downstream models can reference clean, standardized building blocks instead of re-cleaning raw data repeatedly.
• 2Use the ref() function to build on other models rather than duplicating SQL logic across multiple models; this also ensures proper dependency resolution and lineage in the DAG.
• 3Repeated SQL snippets (e.g., business logic like calculating a discount or a common CASE WHEN) should be extracted into Jinja macros so the logic is defined once and reused across many models.
• 4Intermediate models are used to encapsulate complex or reusable transformation logic between staging and mart layers, preventing the same joins or aggregations from being rewritten in multiple downstream marts.
• 5Variables (vars) and dbt_utils/date-spine style packages help avoid hardcoding values or reinventing common utility logic, supporting DRY across an entire project.
• 6Over-modularizing (excessive layering of trivial models) can hurt performance and readability, so modularity should be balanced with the actual reuse and clarity benefits it provides.

2 · Check your understanding