Domain structure is a critical aspect of a well-designed operating model. The recommendations here will help you design your domain structure to achieve these objectives.

Impact

Following these best practices will support platform adoption by improving:

Platform usability.
Clarity of governance responsibilities.
Ease of system.

Best practice recommendations

Domains are collections of assets with similar characteristics, attributes or similar responsibilities or roles. When deciding how to group assets into domains, think about which assets will be acted on similarly within the system. For example, assets that have the same governance process or are assigned similar responsibilities.
Since assets can only be a member of a single domain, you may run into situations where it is hard to decide between 2 or more possible domain assignments. For example, an asset that might have stewards in a geographically defined domain, such as the North America Group, and a business-function-defined domain, like Finance. In these cases, you should choose the domain of the ultimate “owner” of the asset.
These decisions will sometimes drive the need to create new communities or even shared communities. For more information, go to the Community structure best practice article.
Only create domains when you have a set of assets which will belong to them. Empty domains can cause clutter and confuse your users.
Domain names must be unique within a single community but can be duplicated across communities. However, it is best to name each domain uniquely. For instance, instead of having a Glossary domain within multiple communities, give them specific names such as Finance Glossary and Marketing Glossary.
Add a description to your domain. It is a best practice to provide a clear and useful description for users who may not otherwise be familiar with the content.
While all domains are visible to everyone by default, it is possible to hide domains from view based on users or groups. However, it is a best practice to use this feature sparingly and only where it is clearly required. For example, a domain of sensitive reference data, like salary scales should have restricted visibility.
While enabling automatic hyperlinking is not recommended, when using it, it is necessary not only to enable the system-level automatic hyperlinking but also specifically for the domains whose assets you want to be hyperlinked. This should be applied judiciously to smaller, business asset domains rather than broadly to avoid performance issues since the links are dynamically maintained.

Validation criteria

The Operating Model Diagnostic workflow, which is available from your Customer Success representative, will help identify empty domains and domains without descriptions, as well as domains without stewards and domains where automatic hyperlinking is enabled.
The Operating Model Reverse Engineering, OMRE, available in Marketplace, can make it easier to find duplicate-named domains across communities.

Additional information

For more information, go to the following resources:

See the Collibra Documentation Center for more information on any of the above elements.
You can run the OMRE to help identify the existence of duplicate domain names across communities.
Domain structure and community structure work together so our Community structure best practice is another useful resource.