Skip to main content

​
When would you use this?

  • Different teams need different slices of the same model, each with its own entity scope, filters, or field-level access.
  • You want governance rules (filters, PII restrictions) defined once and inherited automatically, so child domains stay in sync when the parent changes.
  • You need to compose multiple concerns - for example, a product filter combined with PII restrictions - without duplicating configuration.

​
What this recipe builds

A five-domain hierarchy where a base domain defines shared governance, a team domain narrows entity scope, an executive domain strips PII fields, a filter domain narrows to healthy menu items, and a composed domain combines the filter with PII removal via multiple inheritance.
This recipe uses domain hierarchy. See the documentation for the full technical reference.

​
Steps

1

Base domain

The foundation domain includes all entities and a baseline governance filter that excludes zero-dollar orders from every analysis. Every other domain extends this one.
type: domain
name: tasty_bytes_core
display_name: Tasty Bytes Core
description: |-
  Foundation domain. All entities are in scope. A baseline
  filter excludes zero-dollar orders.
entities:
  - name: order_detail
  - name: order_header
  - name: menu
  - name: date
  - name: truck
  - name: shifts
  - name: customer_loyalty
filters:
  - name: exclude_zero_dollar_orders
    sql: order_header.order_amount > 0
    display_name: Exclude Zero-Dollar Orders
    description: Remove zero-dollar orders from all analyses.
2

Fleet operations domain

The operations team manages trucks and shifts but does not need menu items or customer demographics. This domain extends the base and removes menu and customer_loyalty using merge: remove.The inherited filter (exclude_zero_dollar_orders) applies automatically - no need to redefine it.
type: domain
name: fleet_operations
display_name: Fleet Operations
description: |-
  Operations team view. Truck and shift data for
  fleet scheduling and logistics.
extends:
  - tasty_bytes_core
entities:
  - name: menu
    merge: remove
  - name: customer_loyalty
    merge: remove
Result: order_detail, order_header, date, truck, shifts - with the zero-dollar filter inherited.
3

Executive domain (PII-free)

Executives need aggregate analytics but must not see personally identifiable information. This domain extends the base and uses field selectors to strip PII from customer_loyalty - names, email, phone, postal code, and birthday.Fields like customer_id, city, country, age_group, and favourite_brand remain available for aggregate analysis.
type: domain
name: executive
display_name: Executive (PII-free)
description: |-
  Executive view with PII stripped from customer data.
  Preserves aggregate analytics fields.
extends:
  - tasty_bytes_core
entities:
  - name: customer_loyalty
    fields: ["-first_name", "-last_name", "-e_mail",
      "-phone_number", "-postal_code", "-birthday_date"]
All fields are inherited by default, so the child only needs to list exclusions. Each -field_name selector removes one PII field from the inherited set.
4

Healthy items domain (filter)

A domain that narrows the data to healthy menu items only. It extends the base and adds a filter - all entities remain available.
type: domain
name: healthy_items
display_name: Healthy Items
description: |-
  Healthy-items view. Adds a filter for menu items
  flagged as healthy.
extends:
  - tasty_bytes_core
filters:
  - name: healthy_only
    sql: menu.is_healthy_flag = true
    display_name: Healthy Only
    description: Restrict to healthy menu items.
Result: all seven entities, the inherited zero-dollar filter, plus the new healthy-only filter.
5

Composed domain (multiple inheritance)

The healthy items executive domain combines two concerns: the healthy filter and the executive’s PII restrictions. It extends both parents with no additional configuration.
type: domain
name: healthy_items_executive
display_name: Healthy Items - Executive
description: |-
  Composed view: healthy items filter with
  executive PII protections.
extends:
  - healthy_items
  - executive
Result:
  • Filter from healthy_items - healthy items only
  • Fields from executive - no PII on customer_loyalty
  • Filter from tasty_bytes_core - exclude zero-dollar orders
  • Zero duplication - everything is inherited

​
Key design notes

  • Filters inherit and can be replaced - a child inherits all parent filters. A filter with the same name replaces the parent’s version.
  • Field selectors extend the parent - child field operations apply on top of the inherited field list. Use -field_name to remove fields, or -* then explicit names to restrict to a specific subset.
  • merge: remove narrows scope - use it to drop any inherited item - entities, filters, or parameters - without touching the parent.
  • Multiple inheritance composes - parents are evaluated left-to-right. If both parents define the same item, the rightmost parent wins. The child overrides all parents.
  • Domains - full reference on domain configuration, filters, and field selectors
  • Domain hierarchy - inheritance rules, merge: remove, and multiple inheritance
  • Row-level security - combining domain hierarchy with warehouse-level access control