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.
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.
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.
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.
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.
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