Domain-Driven Design for Microservices

Domain-Driven Design Microservices Approach

Domain-Driven Design microservices are the key to simplifying microservice application development. Microservices are small functions that solve a particular business problem. Decomposing your monolithic applications into microservices requires you to define these business functions into domains of expertise called Domain-Driven Design (DDD).

Article Contents:

• What is Domain-Driven Design in microservices?
• Domain-Driven Design microservice supply chain
• DDD: a short history lesson
• Domain-Driven Design microservice catalog
• DeployHub’s Unified Microservice Catalog

 

What is Domain-Driven Design in Microservices?

Initially coined by Eric Evans, Domain-Driven Design (DDD) is defined as designing software systems based on the underlying model of the business domain. Domain-Driven Design has an organizational relationship to microservices and categorizes them so their usage is easily understood.

A microservice is written in ‘bounded context,’ meaning its function is narrowly defined. Organizing microservices helps determine a microservice strategy that encourages collaboration and re-use across a siloed organizational structure. It is essential to organize microservices in terms of high-level Domains (who they serve) and low-level Domains (what they do).

Domain-Driven Design Microservice Supply Chain

Domain-Driven Design will be your blueprint for identifying what you need in your microservice supply chain. Domain-Driven microservices simplify what is problematic about microservice application development, knowing what needs to be written.

The challenge in microservices is how a developer communicates the availability of a new microservice. Developers tell application teams where to find it, what it does, how to use it, and how it should be deployed. Encouraging collaboration between teams requires a process for communication. Domain-Driven Design can be a platform for communicating the availability of microservices, who owns them, consumes them, and how to use them.

Domain-Driven Design Microservices approach is essential for eliminating microservice sprawl. Without the organizational benefits of Domain-Driven Design, each project team may write its own set of services, a costly mistake in a microservice architecture. After all, how many log-on services do you need? The answer is just one.

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 by creating 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 re-used 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.

Why DDD Failed in OOP

The primary reason that Domain-Driven Design failed in OOP was the inconsistent methods of managing the link step of the compile or ‘make’ process. With a purely scripted build, controlling where a library was referenced at the link step was 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 Microservice

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 toward Domain-Driven Design microservices.

There are also great books on the topic that will help you understand why Domain-Driven Design is essential in building a microservice application architecture.

The following are the features that a microservice catalog should include:

Easily Share Domain-Driven Microservices

A Microservice Catalog should make sharing Domain-Driven Design microservices easy. Developers publish their microservices to a specific high-level Domain along with the critical deployment metadata such as ownership info, deployment method (Helm chart), container registry, and usage. The catalog should also track where the services have been deployed, creating an inventory based on end points.

Versioning

Your microservice catalog should also be a microservice or ‘component’ versioning solution. Once a component is registered to the Catalog, any update creates a new version of the component tracking the most recent version of the microservice and what changed.

Categorize Microservices

A microservice catalog should allow you to define your Domain structure freely. 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.

Microservice Attributes

A microservice catalog should manage attributes of a microservice. These attributes include ownership, container image repository, deployment requirements, key-value pairs, swagger data, licenses usage, consuming applications, and CVEs. These attributes are critical when developers want to use the service for an incident response when there is an issue.

DeployHub’s Unified Microservice Catalog

DeployHub’s Domain-Driven Design microservice catalog provides a unified location for microservice developers to register their services with attributes. Application developers can quickly search the catalog for services based on Domain and include them in their Application’s package. DeployHub can be used to:

• organize microservices, with sub-domains, based on a ‘business’ or ‘problem’ space
• encourage service re-use and collaboration
• track a service version to an application version, providing a service to application SBOM
• create a self-service deployment dashboard for tracking microservices across teams
• provide ownership information for support teams

4 Levels of Domains

DeployHub’s Domain Catalog includes four levels of Domains:

• Site Domains
• Division Domains
• Project Domains
• Life Cycle Sub-Domains

Site Domain	This is the highest level of your Domain-Driven Design structure. Any microservice defined to the Site Domain is shared with all Division and Project Domains.
Division Domain	Microservice developers register their service to a Division Domain. Division Domains are used to describe 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 particular User Groups. Division Domains allows you to define your DDD for cataloging your microservices and reusable components.
Project Domains	Application teams package their microservice application using 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 at the deployment level.
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.

Conclusion

Let’s face it, without Domain-Driven Design, microservice implementation could become a vast tangled hairball. From our experience around Object-Oriented Programming, we know 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 versions of services. This would not be good. DeployHub provides a collaboration framework to register and share your service across teams using your organization’s Domain-Driven Design model.

DeployHub allows you to publish and share reusable microservices across teams with security. DeployHub’s Domain structure is hierarchical, meaning 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.

Further Reading on Microservices:

• Microservice Catalogs Explored Whitepaper
• Microservice Version Management
• A Microservice Service Catalog for Incident Response
• Know Your Microservice Blast Radius
• Microservice Applications
• Microservice Pipelines
• Microservice Ownership for Improving Incident Response
• Microservice Configuration Management

Get Started – Give DeployHub a Try

• Get Started with DeployHub’s Microservice SaaS Dashboard