The views expressed in my articles are based on my personal experience and understanding, and do not represent official recommendations from Databricks. Peer reviews and feedback are always welcome.
Effective data governance is a prerequisite for organizations seeking to scale data and AI initiatives. Unity Catalog provides the foundational capabilities required to manage data assets consistently across the Databricks platform. It offers a unified approach to access control, auditing, and metadata management—enabling standardization and compliance across diverse data environments.
Core functionalities include fine-grained access control, end-to-end data lineage, and comprehensive audit logging. These features support critical governance objectives such as data security, traceability, and discoverability.
In practice, this enables organizations to reduce operational risk, ensure regulatory compliance, and accelerate the adoption of reliable, production-grade data & AI systems.
Before discussing patterns for organizing assets within Unity Catalog, it is critical to introduce the concept of business scopes. Scopes represent the logical partitions used to cluster and manage assets within Unity Catalog. They provide a foundational structure upon which governance, access, and lifecycle management are built.
<aside> 👉
The most important principle when defining scopes is ownership.
</aside>
In practice, effective scope design hinges on clear ownership. Scopes must be defined with accountable owners who are empowered to manage and govern the assets within their domain. Without ownership, scopes quickly become ineffective and unsustainable.
Defining scopes is a non-trivial task that often requires creative problem solving. From experience, there are two dominant approaches to scope definition commonly adopted in practice. These can be broadly characterized as follows:
The straightforward approach is to align scopes directly with your existing organizational structure. Business lines, business units, or major projects—each with established ownership and accountability—serve as natural candidates for scope definition.
Figure 1: Common Scope Candidates in Business Structures
This method leverages familiar boundaries within the enterprise, simplifying governance and ensuring clear responsibility across the defined scopes.
The second, more thoughtful approach that requires deeper engagement and intentional modeling. It begins with identifying business subdomains—categorized as core, supporting, or generic—and drawing boundaries around them. While more demanding than a simple taxonomy-driven approach, it provides a clearer path to long-term scalability and agility.
Domain-Driven Design (DDD) offers a strategic approach to defining data domains by aligning technical systems with how the business actually operates. DDD segments complexity into Bounded Contexts—well-defined areas where data models, language, and ownership remain consistent. Each context reflects a shared understanding between business and technical teams, supported by a Ubiquitous Language that promotes clarity and collaboration across functions.
Figure 2: Example of domain modeling for an energy company.
DDD often aligns well with enterprises that are already domain-oriented or in the process of consolidating domains, offering a framework to bring structure and consistency to otherwise fragmented efforts. It reinforces broader initiatives in data governance, ownership, and platform modernization—resulting in a more business-aligned and future-ready data architecture.