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:
|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.
|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:
|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.
|The fully qualified Domain Name including any parent Domains.
|The Name of the Domain.
|User or Group.
|Name of the Owner.
|Auto-generated date when it was created.
|Auto-generated date when it was modified.
|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.
|A list of all Subdomains assigned to this Domain.
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:
|Allows the Group to see the Domain.
|Allows the Group to change the Domain’s characteristics i.e. Name, Summary, etc.
|Allows the Group to see the Domain.
|Allows the Group to create Subdomains.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.