A Domain Driven Design Microservice Approach
Domain Driven Design microservices are the key to simplifying microservice application development. Yes, that is a big statement, and it can be easily proven. Domain Driven Design (DDD) is essential for describing, organizing, finding and sharing small ‘bounded context’ functions. When you begin to decompose your monolithic applications into smaller reusable functions you need a way to define ‘problem spaces’ and the services required to build out your software solutions.
A Domain Driven Design will be your blueprint for what needs to be written and how services must be organized across your organizational siloes. Domain Driven Design microservices simplify what is hard about microservice application development. 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.
Encouraging collaboration between teams requires a process for communication. Domain Driven Design is a platform for managing that communication process. Ever put something away and can’t remember where you put it? This forgetfulness happens often in a microservice architecture which leads to multiple services doing the same thing – what is often referred to as microservice sprawl. After all, how many logon services do you need? The answer is just one. Using a Domain Driven Design in a microservices implementation is the only way to clearly define what services need to be written, and which ones will be shared. The Domain Design is just your blueprint. You also need a Domain Catalog to to register services so they can be found and reused. This is the purpose of the DeployHub Domain Catalog.
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.
What is Domain Driven Design? A Short 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 over time 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.
Learn More About Domain Driven Design
Before you go too far down the road of developing microservice applications, take the time to learn about Domain Driven Design. Check out sites like microservices.io to get started. You will find classes and information to help you move in a direction of Domain Driven Design microservices. There are also great books on the topic which will help you understand why Domain Driven Design is essential in building out a microservice application architecture.
A Domain Driven Design Microservice Catalog
Once you have a Domain Driven Design, you will begin seeing the need for a Domain Catalog. DeployHub’s Domain Catalog is designed to make sharing Domain Driven Design microservices easy. Developers publish their microservices to a specific problem space along with the critical deployment meta data such as ownership info, deployment method (Helm chart), container registry, and deployed locations.
In addition, the DeployHub microservice catalog tool 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 microservice catalog 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 ‘problem spaces’ based on your Domain Driven Design blueprint, organizational structures, geographical areas, or lines of business. DeployHub’s Domain management feature creates a ‘catalog’ of shareable microservices that allows development teams to easily publish and/or reuse microservices across your organization, and provide critical information for incident response.
Domain Driven Design Structure
DeployHub’s Domain Driven Design microservice catalog 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;
- create a self-service deployment dashboard for tracking microservices across teams,
- provide ownership information for support teams.
DeployHub’s Domain Catalog includes 4 levels of Domains:
|Site Domain||This is the highest-level of your Domain Driven Design structure. Any microservice defined 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.
Let’s face it, without Domain Driven Design, microservice implementation could become a huge tangled hairball. 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.
DeployHub Key Features
- Microservice Versioning for Indispensable Clarity
- Simplifying Microservice Applications
- Ship Microservices Safely – Know Your Blast Radius
- Improve Your Incident Response
- Microservice Configuration Management
- Database Updates Pushed Across Your CD Pipeline
Meet the Co-Founders
- Register for DeployHub Team
- Reverse Proxy Setup for SaaS Deployments
- DeployHub Team User Guide
- The Hipster Store Tutorial
- DeployHub Newsletter