A Domain Catalog for a Domain Driven Design

A Microservice Catalog with a Domain Driven Design

Encouraging reuse between teams requires collaboration and communication. Ever put something away and they can’t remember where you put it?  Yeah – that happens often in a microservice architecture.  So the question is, how do teams share reusable microservices easily?  The first step in defining a microserivce architecture is building a Domain Driven Design. Domain Driven Design (DDD) is a method of software development applied to the organization of microservices and other shared objects.  Using a Domain Driven Design makes it easier for developers to categorize, and subsequently find, objects that can be shared across teams.

DeployHub includes a catalog for organizing microservices based on a  Domain Driven Design.  DeployHub’s Domain Catalog allows you to publish and share reusable microservices across teams with security. DeployHub includes a catalog with a domain structure that facilitates a Domain Driven Design approach to tracking, versioning and releasing microservices.  DeployHub domains are hierarchical. This means that a microservice defined to a high-level Domain is shared with all child ‘sub-domains.’ DeployHub’s domains also include security allowing you to restrict or open access to any microservice or reusable component (web components, database SQL scripts, etc).

DeployHub’s Domain Driven Design allows you to define categories of microservices, and to whom they can be shared.  In this way, you can classify your microservices into ‘problem spaces,’ organizational structures, geographical areas, or lines of business.  Domains create a ‘catalog’ of shareable microservices that allows development teams to easily publish and/or reuse microservices across your organization.  DeployHub’s domain Catalog is unique and helps enforce reuse, as opposed to all teams writing their own ‘similar’ services without cross team exposure.


DeployHub’s Domain Catalog includes 4 levels of Domains:


Site Domain This is the highest-level of your Domain Driven Design structure. Any microservice define to the Site Domain is shared to all Division and Project Domains.
Division Domain Division Domains are used to define an organizational structure that closely represents how they do business, such as geographical areas, problem sets, organizational responsibility, or business units.  A Division Domain is a folder of other Sub-Division Domains and Project Domains. Division Domains can create as many Sub-Division Domains as needed. In addition, objects defined to a specific Division Domain can be secured with specific User Groups.  Division Domains adds flexibility to how you define your Domain Driven Design.

Divisional Domains are a DeployHub Pro Feature

Project Domains You assign your software project to a Project Domain. You can create as many Project Domains as needed. Project Domains cannot have child Sub-Project Domains, but they do have Life Cycle Sub-Domains for mapping to a continuous delivery pipeline.
Life Cycle Sub-Domains

This Sub-Domain defines the stages in your Delivery Pipeline. Only Project Domains can have Life Cycle Sub-Domains. You create Life Cycle Sub-Domains to map to each stage in your continuous delivery Pipeline. Life Cycle Sub-Domains allow you to automate the push of your continuous deployments from development through production. DeployHub can be called by your Continuous Delivery Engine (Jenkins, Bamboo, GitLab or GitHub Actions) to perform the continuous deployment across all states of your pipeline. If you are not using a Continuous Delivery orchestration engine, you can assign Tasks to your Life Cycle Sub-Domain to define a continuous delivery process.

You can create as many Life Cycle Sub-Domains as you need for each of your Project Domains. You can also rename Life Cycle Domains if your Pipeline changes. Lifecycle Sub-Domains can be dragged and dropped in their General tab to rearrange their top-to-bottom execution order within the Domain where they exist. Rearranging Lifecycle Sub-Domains allows users to manage and organize the visual representation of their Continuous Delivery Pipeline.  Lifecycle Sub-Domains are represented by a circular multi-object icon under your Project Domain tree-structure.

domain driven design


DeployHub’s Domain Driven Design structure can be used to:

  • group ‘like’ microservices together as a package;
  • organize, with sub-domains, based on a ‘business’ or ‘problem’ space;
  • encourage re-use and collaboration;
  • track a Service version to an application version, providing a single source of truth.


Lots of Information to Share

Lets face it, implementing microservices could become a huge tangled hair ball without a Domain Driven Design.   We know from our experience around Object-Oriented Programming that sharing and collaborating around the use of services will become critical for their success. We know we’re failing when each team begins to ‘copy’ and ‘rename’ their own versions of services.  This would be bad. DeployHub’s Domain catalog provides a collaboration framework so that your service can be published and shared across teams. This allows them to choose a service from a Component list.  Providing a central repository of the available services also reduces the temptation of taking an older version of a service and making it ‘our own.’  Domain Driven Design is easiest to follow when you have a central tool to organize and share the microservices.  DeployHub does this through organizing,  packaging, and versioning your services before the deployment.

Life Cycle Domains – Their Purpose

DeployHub’s Pipeline contains all information for a Domain concerning the deployment of Applications and their movement through the Life Cycle Sub-Domains contained within. It is designed to show and keep track of the procession of Applications  and their associated microservices through the continuous delivery pipeline, as well as the deployment into Environments. Keep in mind that when dealing with software life cycles within DeployHub, parent Domains contain Life cycle Domains, and these contain Applications and Environments. DeployHub’s pipeline can map to your continuous delivery orchestration engine and aggregate many microservices into a single application package for deployment, and versioning.


Get Started

To begin tracking your microservice death star, sign up with DeployHub Team.  This option is based on the open source Ortelius Project. It is provided for free and hosted for high performing development teams who want to manage Services in the new modern architecture.

Key Features

Leave a Reply