Domains are the tables that exist toward the end of the mastering process. These are essentially enriched entities, which contain data from other entities, for example the orders domain may contain information from the order line item entity, customer entity, product entity and marketing entity. All of these entities sit on different levels of granularity, so would have to be aggregated in some way to join onto the orders entity without creating duplicates. Moreover, the orders domain being one order per row, would contain customer information such as their record created date, order line item information such as the count of line items, count of discounted items etc.

The image below shows a DAG leading to a marketing domain table (far right node) from multiple data sources.


A DAG mapping out a marketing domain table (far right node) created as a result of multiple data sources.

The benefit of housing all insights layer tables in one schema is that it makes it easier to have the business use one schema for all insights, thereby reducing the potential of data siloes forming.

All domains reside in the dw schema, where ‘dw’ stands for ‘data warehouse’. All domain tables follow a similar nomenclature to that of the entities, thus <collection_name>_domain. For example, the orders domain would be dw.orders_domain.