Building Your Domain Catalog

A Domain Driven Design

An Ortelius Domain is how Ortelius organizes and shares data across teams. You publish your Components to a Domain, you package your Application in a Project Domain and you track your continuous delivery pipeline with a Life Cycle Domain. All Ortelius objects are assigned to a Domain.

For this reason, it may be helpful to review how you might want to organize your data in Domains. Domain organization is not required, but makes finding and sharing information much more efficient.

Domains and your Domain Driven Design

A Domain-Driven Design (DDD) is often used when moving from a traditional development model to a cloud-native, decoupled model. With microservices, it is often recommended that a structured method for organizing microservices into “solution” spaces be completed to facilitate reuse across siloed teams. Ortelius Domains provides this organization.

Domains publish microservices and other reusable objects (web components, DB updates, etc.) making it easier to share Components across siloed teams. Domains can be structured to closely resemble the patterns of your organization. They can represent functional areas such as ‘security services’ or departments, teams, geographical locations and software projects.

Top Down Structure

Everyone has a single high-level “Global” Domain. All other Domains are Subdomains.

A Subdomain inherits all the access properties from its parent Domain. This inheritance continues down through all Subdomains.

There are four common ways to implement Domains:

Purpose	Description
Site Domain	This is the highest-level and default Domain. Your default Site Domain name is ‘Global.’ You can rename your Site Domain if needed. Anything defined to this level can be shared across all lower level Subdomains. For example, Environments and Tasks defined to the Site Domain are shared by all child Subdomains.
Catalog Subdomains	These Domains are used to organize reusable Components, such as microservices. At this level, you create as many Subdomains as needed to represent your Component organization based on the “solution space” they serve. For example, you could build your Catalog as follows: Security Services Purchase Processing Data Access Ad Services A Catalog Domain does not contain Life Cycle Domains.
Project Subdomains	Use a Subdomain to represent your software Application and its Life Cycle. A Subdomain defined for an Application may need a continuous delivery life cycle. This is defined by selecting “All Subdomains are Life Cycles.” This means that any Subdomains cannot include any additional Subdomains and will be used to represent stages of the Pipeline with specific Environments assigned.
Life Cycle Subdomains	This is the lowest level of Subdomain. It is available when the parent Domain has “All Subdomains are Life Cycles” selected. These Subdomains map to each stage in your continuous delivery pipeline. They often have specific Environments and Tasks assigned for interaction with your continuous delivery orchestration engine. Ortelius can be called by your continuous delivery Engine (Jenkins, Jenkins X, CircleCI, Google CloudBuild, GitLab or GitHub Actions, etc.) to perform the continuous configuration management of your microservices and Applications across all lifecyle states. In addition, you can assign Move, Approve and Request Tasks to your Life Cycle Subdomain to define a continuous delivery pipeline process within Ortelius that can interact with your pipeline process.

Below is an example of how an Online Store Company organized their Domains.

Using the Domain Dashboard

A full view of all Domains is based upon your User privileges. The view is displayed in a “Sunburst” map, starting at the highest level Domain with the ability to drive down into the Subdomains, and Subdomains after that. Clicking on a segment in the Sunburst map will take you to that Domain. Clicking on the center of the Sunburst will take you back up the Domain structure.

When scrolling up or down the Domain hierarchy using the Sunburst map, the detail information is re-displayed according to where you are in the map. Below are the details for a Domain.

Domain Details

Details	Description
Full Domain	The fully qualified Domain Name including any parent Domains.
Name	The Name of the Domain.
Summary	Domain Description.
Owner Type	User or Group.
Owner	Name of the Owner.
Created	Auto-generated date when it was created.
Modified	Auto-generated date when it was modified.
Engine	The hostname of the deployment engine. Defaults to “Deployment Engine.” This field can be used to specify another Ortelius Deployment Engine for widely distributed deployments.
All Subdomains are Life Cycles	This specifies that the Domain will include a Pipeline model and all following Subdomains will model the pipeline states. Life Cycles are specifically for Project Subdomains. Life Cycle Domains cannot have any further Subdomains and are not appropriate for defining a Catalog Domain.
Subdomains	A list of all Subdomains assigned to this Domain.

Access Control

Users within the designated Groups of “User” or “Admin” can update the Domain in various ways. To add a Group to one of the access lists, drag and drop the Group from the Available Groups list onto the desired access list. All Users who belong to a Group in one of the Access lists will be granted access to the Domain. Access control for Domains include:

Access	Description
View	Allows the Group to see the Domain.
Change	Allows the Group to change the Domain’s characteristics i.e. Name, Summary, etc.
Read	Allows the Group to see the Domain.
Write	Allows the Group to create Subdomains.