Using Domain Driven Design for Microservices

Organization for Re-use

Using a Domain Driven Design (DDD) is a method of software development applied to the organization of microservices.  Using a Domain Driven Design makes it easier for developers to categorize, and subsequently find, microservices that can be shared across teams.  DeployHub includes a Domain structure that facilitates a Domain Driven Design approach to tracking, versioning and deploying 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 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 Architecture 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 architecture 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.

Further Reading on Domains

For more information on DeployHub’s Domains, refer to the User Guide Section on “Using Domains.

More Information