Microsoft Fabric Domains: Stepping Stones for Data Mesh

Microsoft Fabric introduced a new concept called Domains. Domains are more than just a separation of Fabric data items. They come with a whole lot of security, administration, and governance features, which brings the concept of data mesh into the world of data analytics using Microsoft Fabric. Domains are logical categorizations inside the OneLake. In this article and video, I will explain what domains are in Microsoft Fabric, why they are important, and their associated features and configurations.

Video

Microsoft Fabric

Microsoft Fabric is an end-to-end Data Analytics software-as-a-service offering from Microsoft. Microsoft Fabric combined some products and services to cover an end-to-end and easy-to-use platform for data analytics. Here are the components (also called workloads) of Microsoft Fabric.

Microsoft Fabric

To learn more about Microsoft Fabric and enable it in your organization, I recommend reading the articles below;

Data Mesh: What and Why?

Organizations these days have data everywhere and in every business unit. People in the organization deal with the data items in their day-to-day jobs. Making the data accessible to the people in the organization can have different types of approaches, also called architectures. One of the common architectures these days is Data Mesh.

Data Mesh is working on the concept of decentralizing data into business domains. For example, marketing, sales, etc. Having multiple business domains or categorizations for the data helps set up ownership, access rights, governance, and self-service.

In the concept of Data Mesh, the data entities might be categorized into business domains like the below;

In the Data Mesh architecture, you can have databases, data warehouses, data marts, etc., under each node (also called a domain). However, because different business departments are interconnected, their data should also be interconnected. That is why you see the lines between the domains.

Fabric Domains: Data Mesh in Fabric

Microsoft also provided data mesh capabilities in the Fabric as an end-to-end data analytics solution. Workspaces previously provided this ability inside the Power BI Service. However, the concept of Domain is more than just a workspace. What if you want to categorize items inside a domain? Inside a workspace, you cannot create another workspace. What if you want an owner for the whole domain plus an owner for each workspace under the domain? Other limitations in the workspace caused the creation of the Domains in Fabric.

Domains are logical groups inside Fabric for items related together for a particular business group. For example, you can have a Domain for Sales and another for Marketing. Domains are logical groups because they all use the OneLake (and under that ADLS Gen2) storage engine underneath. The entities inside domains can split into further categories using Workspaces. Inside workspaces, you can have Fabric items (such as Lakehouse, Warehouse, Dataset, Dataflow, Datamart, etc.)

The diagram below shows how Domains and Workspaces work together;

Shortcuts and OneCopy

Although Shortcuts and OneCopy require a separate article (coming soon), it is important to mention them here briefly. When you have data items in different domains, one of the main challenges would be accessing a domain’s entities from another domain inside the same tenant. OneLake has this wonderful feature of OneCopy using Shortcuts, which allows the items of one Domain to be useable inside other domains without needing to move or duplicate the entity.

Shortcut items will be like links inside the Fabric Data items and work seamlessly like an internal item. For example, you can have a Lakehouse with one internal table and one external table using a shortcut from a table in a Lakehouse from another domain, and then, using SQL commands, you can query data from both tables.

Role Distribution Across Tenant, Domain, and Workspace

As the Tenant, Domains, and Workspaces structure is hierarchical, the access roles are distributed well for it. You can have different levels of administrators and contributors in this structure. Here are some of these roles;

I have previously explained the Workspace roles and how the role controls the creation or sharing of Fabric items. Let’s talk about the Domain roles here, then;

Domain Contributor

These are workspace administrators who are authorized to assign their workspaces to Domains.

Domain Administrator

Domain admins have full access to the Domain page; they can set up the Domain image, configure the details of it, or add or remove Domain contributors. They cannot delete the Domain or other Domain Administrators, though. Ideally, Domain admins are the business data owners of that domain.

Fabric Administrator

Fabric Admin can create, edit, and delete Domains, Add Domain Admins and Contributors to it, and set the configurations of the domains.

Domains in Action

Now that you know what the Domains are, what they do, and how helpful they are, let’s see them in action and how they work.

Creating and Configuring Domains

To create the domains in the first place, you need to be Fabric Admin and go to the Admin Portal;

The Admin Portal has a section for Domains where you can create a new domain.

There are a few settings needed for each Domain. These start with the Domain Name and description;

The Domain image will be helpful to easily distinguish the Domain when you filter it in the OneLake Data Hub or on the Domain page itself.

The screenshot below illustrates that Domain Admins and Domain Contributors can be assigned easily on the configuration page.

You can also assign workspaces to the Domain or unassign them. Workspaces can be assigned by their names individually or all workspaces from a specific admin or under a specific capacity.

You can also change some of the settings at the Domain level and overwrite the changes from the Tenant level. At the time of writing this article, the only settings available are the endorsement and certification. However, I am sure more settings will come here in the near future.

Once the Domain is created and configured, it will be visible in a few places like the one below.

Seeing and Setting Domains from the Workspace

If the workspace is assigned to a Domain, you can see a small link icon beside it showing which Domain this is assigned to.

You can also change the assigned Domain (if you have enough privilege to do so) under the Workspace settings.

OneLake data hub

Another place where the Domain selection will be possible and helpful is under the OneLake data hub. You can filter items and see the Domain image there, too.

Designing Domains and Workspaces

Domains are different from the Workspace, as you learned in this article. Workspaces will be used to categorize the Fabric items inside the Domains. With that, you may ask: How should I design Domains and Workspaces now? The Workspace design itself was a journey itself. Now, combining it with Domains might make it even more challenging.

An easy way to see it is Domains representing business data units. If there is a need for a part of the business to own its data entities and processes around it, then it makes sense to create a Domain for it. And under the Domain, you can design workspaces based on the access level of data analysts and developers to the Fabric items. This is very generic advice, Of course. The actual design of Domains and Workspaces would require a separate article. I have previously written about some best practice designs for Workspaces; I will write another article about combining that with Domains, so stay tuned.

Summary

These days, businesses have data everywhere. A standard architecture that helps is a decentralized, business-domain based Data Mesh. In Data Mesh architecture, Fabric items can be separated into Domains. Each Domain can have some configurations and access levels. Under each Domain, there will be Workspaces where the Fabric items will be created and maintained.

Domains make the Data Mesh architecture possible inside the Microsoft Fabric. They can be interconnected using OneLake features such as OneCopy and Shortcuts so that the users of other Domain entities (if they have enough privilege) can use the entities from other Domains inside their entities seamlessly.

An important thing to consider is that Domains are just logical groupings in the OneLake. OneLake provides a single lake for the organization through a logical layer on top of the Azure Data Lake Gen2. So, all the data is underneath stored in ADLS Gen2.

Reza Rad on FacebookReza Rad on LinkedinReza Rad on TwitterReza Rad on Youtube
Reza Rad
Trainer, Consultant, Mentor
Reza Rad is a Microsoft Regional Director, an Author, Trainer, Speaker and Consultant. He has a BSc in Computer engineering; he has more than 20 years’ experience in data analysis, BI, databases, programming, and development mostly on Microsoft technologies. He is a Microsoft Data Platform MVP for 12 continuous years (from 2011 till now) for his dedication in Microsoft BI. Reza is an active blogger and co-founder of RADACAD. Reza is also co-founder and co-organizer of Difinity conference in New Zealand, Power BI Summit, and Data Insight Summit.
Reza is author of more than 14 books on Microsoft Business Intelligence, most of these books are published under Power BI category. Among these are books such as Power BI DAX Simplified, Pro Power BI Architecture, Power BI from Rookie to Rock Star, Power Query books series, Row-Level Security in Power BI and etc.
He is an International Speaker in Microsoft Ignite, Microsoft Business Applications Summit, Data Insight Summit, PASS Summit, SQL Saturday and SQL user groups. And He is a Microsoft Certified Trainer.
Reza’s passion is to help you find the best data solution, he is Data enthusiast.
His articles on different aspects of technologies, especially on MS BI, can be found on his blog: https://radacad.com/blog.

Leave a Reply