Skip to main content

Domain Driven Design History Lesson

Domain Driven Design (DDD) was first used in Object Oriented Programming (OOP).  Its purpose was to improve product quality and reduce redundant coding through the creation of library ‘solution’ spaces (also referred to as ‘problem’ spaces.)  The goal of  Domain Driven Design was to define what libraries were needed that could easily be reused across all enterprise development teams, thus standardizing on common code.  Common solution spaces in OOP included centralized logging, standard error messages, database calls and access routines.

The primary reason that Domain Driven Design failed in OOP was in the inconsistent methods of managing the link step of the compile or ‘make’ process.  With a purely scripted build, controlling where a library was being referenced at the link step was at best obscure.  The result, each Build Engineer would determine the repository or build directory from which to pull the common library.  Standardizing a scripted compile/link process was next to impossible. Domain Driven Design in OOP was a great starting point, but overtime became diluted as each team pulled different versions of the libraries, renaming them before the link step of their final binaries.  At best common code became ‘copied’ code, and the promise of shared code was lost.

Domain Driven Design for Managing Microservice Sprawl

In a microservice architecture, Domain Driven Design has the potential to succeed.  We no longer are dependent upon build scripts to control the linking of common services. The link step, a failure point in OOP, is delayed until runtime. Microservices are loosely coupled and linked via APIs.  There is nothing static about microservices which gives us a new opportunity to implement Domain Driven Design.  In fact, a Domain Driven Design is more critical now to control microservice sprawl.  The challenge in microservices is how a developer communicates the availability of a new microservice, telling application teams where to find it, what it does and how it should be deployed. This is the purpose of the DeployHub Domain Catalog.

Encouraging reuse between teams requires a collaboration and communication platform.  This level of sharing goes beyond what can be done via simple Slack or Email communication. Ever put something away and can’t remember where you put it?  This forgetfulness happens often in a microservice architecture adding to your microservice sprawl. After all, how many logon services do you need?  The answer is just one.  The DeployHub microservice platform includes a Domain Driven Design catalog for solving the problem of organizing and sharing common services.

DeployHub’s Domain Catalog allows you to publish and share reusable microservices across teams with security. DeployHub’s Domain structure is 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) based on a User Group.

DeployHub’s Domain Catalog

DeployHub’s Domain Catalog is designed to make sharing microservices easy.  Developers publish their microservices to a specific solution space along with the critical deployment meta data such the Helm chart and container registry. Other developers can then consume the microservice without the need to create their own deployment logic.  In addition, the DeployHub catalog acts as a microservice or ‘component’ versioning solution. Once a component is defined to the DeployHub Domain Catalog, any update to the component creates a new version of the component keeping everyone in the loop as to the most recent version of the microservice.

DeployHub’s Domain Driven Design allows you to define categories of microservices, version the changes and determine to whom they can be shared.  In this way, you can classify your microservices into ‘solution spaces’ based on your organizational structures, geographical areas, or lines of business.  DeployHub’s Domains create a ‘catalog’ of shareable microservices that allows development teams to easily publish and/or reuse microservices across your organization.

Domain Driven Design Structure

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

  • group ‘like’ microservices together as a package;
  • organize microservices, 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.

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 you do business, such as geographical areas, problem sets, organizational responsibility, or business units.  A Division Domain is a folder of other Sub-Division 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 for cataloging your microservices and reusable components.


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 Environments where they will be deployed. Project Domains are integrated into your continuous delivery pipeline.
Life Cycle Sub-Domains

Life Cycle Sub-Domain map to Environments 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, CircleCI, GitLab, GitHub Actions, etc.) to perform the continuous deployments 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.

domain driven design



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 using the Domain Driven Design that your organization created. This allows developers to choose a microservice or component version from the catalog adding it to their application package.  Domain Driven Design is easiest to follow when you have a central tool to organize and share the microservices.  DeployHub achieves this through a Domain catalog that is shared across teams and organizational silos.