Building Your Domain Catalog

How to Create and Manage Domains

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 decoupled architecture, it is recommended that a structured method for organizing shared services into “solution” spaces be completed to facilitate reuse across teams. Ortelius Domains provides this organization.

Domains publish Components (microservices, artifacts, web components, DB updates, etc.) making it easier to share Components across 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. 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 Components and Applications across all lifecycle 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.

    Example of Domains, Applications, Components and Environments

    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

    There are two User Groups, Users and “Admins” You can define high-level security to these Domains for these two Groups.:

    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.