Introduction

Microsoft Fabric encourages a broader audience of people to collaborate on the same platform than what we are used to.

Backend Developers, Frontend Developers and End Users are all logging in to the same website, and the lines dividing where each role starts and stops are more blurred than ever.

A topic which seems more relevant than ever, is the question of how to organize the contents of your Microsoft Fabric Platform.

Through the contents of a few blogs, I will give you an overview of things to consider, as well as suggestions that you can choose from when designing your platform.

This first week, we’ll take a look at Domains in Microsoft Fabric.

What do you want to achieve?

A well designed data platform is a system of empowerment, not a system of oppression. This means, that the platform needs to accommodate the needs of the business, rather than forcing the business to change its ways in pursuit of limitless conformity.

All within reason, of course. I firmly believe that a good Data Platform project is also a chance to revisit Business Processes which are no longer practical or optimal. But I hope you agree with me, that you should not design a Data Platform without involving the organization who will use it.

The same goes for the relatively innocent topic of content organization, which is just one of many Data Platform architecture topics.

To organize your Platform content effectively and efficiently, you need to ask yourself: What do you want to achieve?

Below are a non-exhaustive list of outcomes that I see people balancing with their Platform design:

• Security of Platform – Principle of least privilege
• Ease of Use of Platform
• Discoverability of data products
• Quality and Consistency in solutions and data
• Separation of Developer Duties
• Segregation of Governance Duties
• Collaboration between Platform Participants

Some of the above overlap. Some of them are in direct conflict with one another. All of them are relevant topics to carry with you into the discussions of how to organize your data platform on Microsoft Fabric.

The value of Domains

Domains in Microsoft Fabric are a metadata construct which allows for grouping together Workspaces (more about them later).

Today, they have little technical impact, outside of acting as a filter/discoverability tool within your Platform, as well as allowing for limited delegation of governance responsibilities in the shape of certain delegable tenant settings. I think it is fair to expect that more features will be customizable at Domain-level as we see Fabric mature further.

While I don’t want to downplay the benefits of being able to use Domains as a filtering tool within OneLake Catalog, or as a dimension in your Platform Monitoring tools, the majority of the value from Domains, if you ask me, comes in a less tangible Governance shape.

Grouping Workspaces, and consequently the Data Products they contain, gives you the opportunity to divide and narrow the scope of Governance duties on your platform.

Instead of it being a Platform-wide responsibility to keep tabs on Data Quality in your Data Products – Make it a Domain-wide responsibility. The same could be the case for:

• Documentation
• Data Catalogue
• Data Stewardship
• Endorsement moderation
• Access/Permission audits
• Product Performance Monitoring

Structuring your Domains

Now the great question is: Which Domains should I create?

Unfortunately there is not one answer, but I will do my best to outline the possibilities, and to give you my recommendation.

Microsoft themselves highlight multiple different structures you can pursue (Best practices for planning and creating domains in Microsoft Fabric – Microsoft Fabric | Microsoft Learn).

They range from using Org. Structure, to Processes, Region or Projects as a way to split your tenant.

Personally, I think a better place to start, is athe strategic discussion as outlined in this blog by Alessio Cesana Efficient Data Domains Organization | by Alessio Cesana | Medium, of Source-aligned vs Consumer-aligned Domains (a classic data mesh discussion).

Source-aligned (Organizationally owned) Domains vs Consumer-aligned (Business Owned) Domains

The discussion you need to have, is whether to organize your Fabric Data Platform contents based on the sources used, or based on the end user needs of the business.

Source-aligned Domains work wonders for ensuring consistency in data from source to end-product. You can reuse many of the principles (governance, usage, development) that you are likely already using for your source system itself.

Metrics will be consistent with the source across the domain, End Users will have an easy time understanding your products and an equally easy time figuring out where to ask questions and to whom.

That sounds great! What’s the catch?

Well, how often do you need to combine data from multiple source systems, even unrelated ones, in the same Data Products? Often, I would guess.

In small organizations, this might not be an issue, as the same people could very well own several different source systems. But as organisations grow in size, and the source system landscape grows in tandem, governance accountability and responsibility has to narrow its scope.

The consequence is that you will have a large number of Data Products, organized in Workspaces in Fabric, which doesn’t fit one single Domain in your Source-aligned Domain strategy.

The obvious alternative is therefore of course to center your domains around the business value and processes they need to create and support, going for a Consumer-aligned Domain Strategy.

Such a strategy allows Data Products to be cross-functional. They may contain data from multiple sources, see collaboration between multiple departments and roles, and be exposed to a wider audience of end-users.

The catch here you ask?

Well of course you give up many of the benefits of the Source-aligned perspective. How do you enforce that domains are using data from the same source the same way? How do you ensure that metrics are consistent between data products? How do you prevent duplicate work/promote reusability?

Designing a multimodal Domain Strategy for Microsoft Fabric

If you find yourself thinking that none of the first strategies work for you, I don’t blame you. Frankly, I think they are both theoretical constructs, which have no basis in reality.

No organization will likely not be able to fully commit to either of the two scenarios above. And maybe you don’t have to. Maybe you can have both!

I firmly believe we need to think a little outside the box and ask: Do we even need to force ourselves into one single paradigm here?

If the Source-aligned strategy works best from a Governance perspective, while the Consumer-aligned strategy works best from a business value perspective. Why not design your Domain Strategy to have both?

You could use Source-aligned domains for:

• Ingestion, Storage, Standardization tasks within Microsoft Fabric, consistent with the practices of the Source.
• Perhaps you may even build shareable models, metrics and reports, if this can be done within the boundary of the source domain, but if this doesn’t make sense, leave it to the Consumer-aligned Domains.
• Carryover governance principles from the source systems through to your Fabric Domains, including Data Stewardship and Ownership.

And then you could use Consumer-aligned domains for:

• Business driven data solutions which combine data originating from multiple Source-aligned domains – e.g. Curated/Gold Layer Lakehouses, Semantic Models and Reports, which do not easily fit inside a single Source-aligned domain.
• Business governance principles, allowing the business to take ownership of end-user facing data products.

Of course, this is no simple exercise, and requires careful consideration, especially regarding rules, roles and responsibilities when data from Source-aligned Domains are being used in a Consumer-aligned Domain.

Likewise, you need to establish whether Consumer-aligned Domains are allowed to handle ingestion/transformation from Sources themselves at all, or if any such task needs to be done in a Source-aligned Domain.

Regardless, I personally view this multimodal strategy, combining Domains for Source specific work and Domains for Business purposes, to be a scenario that is more more likely to see adoption in organisations, than any of the purebred paradigms.

What about subdomains?

Sub-Domains can be used for any of the strategies above – they are just an additional layer of grouping.

Whether you want to combine Region Domain strategy with the multimodal approach suggested here, or perhaps just have an additional layer of granularity for organizing your Consumer-aligned domains, Sub-Domains will allow you to do it.

Creating your Domains

Were you looking for a technical walkthrough of creating Domains?

Well, luck would have it. It is as simple as venturing into your Admin Portal:

Creating and Selecting a Domain allows you to add Subdomains, and allocate Workspaces to Domains and Subdomains:

And finally, the Domain Settings allow you to define Admins, Contributors and specify a Default Domain for Users/Security Groups.

If you’re looking for settings to delegate to Domain Admins, put “Domains” as the search term in the Tenant Settings search bar, and you’ll see that currently there are only two delegable settings:

And for where the Domain metadata can be used on the Platform?

You can use it to filter your Workspaces:

Use it to filter your OneLake:

Or pull it out of the Admin APIs and use it in your monitoring solutions:

Domains – List Domain Workspaces – REST API (Admin) | Microsoft Learn

And that’s about it for the actual technical stuff…

Conclusion

Discussions about Domains often become borderline philosophical and lacks grounding in reality. In practice, few organizations, if any, will be able to conform fully to either the Source-aligned or Business-aligned Domain paradigms, without making serious compromises.

Instead, I am a big proponent of allowing both types of Domains to co-exist in a multimodal strategy.

Using Source-aligned Domains to keep data work under close control and heavy Governance, makes a lot of sense for the backend work you do in Microsoft Fabric.

Similarly, using Business-aligned Domains for workspaces and artifacts which span several sources in the pursuit of serving a business driven purpose, makes a lot of sense especially for frontend facing data products.

Regardless of your choice, taking advantage of Domains will give you a frame of reference which you can use for context in your Governance discussions and decisions, as well as for low practical filtering in your Data Platform interfaces.