Domain-Driven Design

We often consider domain-driven design when building resilient digital experiences for our clients. But what exactly is this concept? How does it work? How does it impact software development?

Let us learn what DDD is about and how can organizations benefit from using its concepts.

A quick primer to Domain-Driven Design

Domain-driven design might sound like a new concept, but it's been around for nearly 20 years.

Programmer Eric Evans introduced the idea in his 2003 book, "Domain-Driven Design: Tackling Complexity in the Heart of Software"—one of the most significant titles in the history of software development, in our humble opinion. 

Since Eric's book, communities of software engineers and developers have built on the principles of domain-driven design to solve the problem of complex domains, which can complicate development workflows. 

Before we explain the domain-driven design quickly, it's important to understand the meaning of domain logic (also called business logic).

In a software engineering and development context, 'domain logic' refers to the software principles that influence business-critical decisions.

In his book, Eric Evans talks about how software should fulfill the business needs of the end users that invest in that software. 

You should also be aware of domain modeling, which shows the relationships between concepts and entities that solve business problems. It helps developers deal with domain logic. 

Keep domain logic and domain models at the front of your mind when learning about domain-driven design. 

What is Domain-Driven Design

Domain-driven design—or DDD, for short—is an approach to software development that solves real-world business problems through code. 

Here's a quick example:

• Say your business needs software with a user-friendly interface to execute day-to-day tasks. Or you require software that improves the automation of complex business frameworks. 
• A developer that uses domain-driven design will create code that solves these problems for your business.

Domain-driven design categorizes microservices—another software development approach where business applications work together but also independently from one another—so end-users can better understand those microservices. 

The primary goal of design-driven design is to standardize language, strategies, workflows, and design patterns when developing an application.

The focus is on the business using the application, not the application itself.

That differs from other software and product development approaches that might minimize development complexity but ultimately concentrate on how a software tool functions in different contexts. 

When to Use Domain-Driven Design

Domain-driven design is a software development approach that suits complex applications requiring multiple workflows.

This approach might benefit your organization if you want to align development with your long-term business goals and end-user requirements. 

Domain-driven design can also improve design maintenance. That's because it has a layered architecture that makes it easy to change and upgrade applications during and after the development process (more on this later). 

Domain-Driven Design Approaches

There are two approaches to domain-driven design:

1. Tactical design
2. Strategic design

Tactical Design

Tactical design refers to the different components (building blocks) used to create a domain model. These components need to work in a specific context for domain modeling to be successful. 

Entities

Entities execute business logic within a domain model and have a unique identifier.

Value Objects

Value objects are like entities but don't have a unique identifier. They can make it easier to create complicated calculations in a domain model. Developers can also use them to isolate logic from entities.

Aggregates

An aggregate is a cluster of entities and value objects within a transaction boundary—where a transaction in microservices starts or rolls back. An aggregate root is the parent entity of the cluster of entities and value objects.

Factories

Factories control the beginning of the aggregate lifecycle. They create aggregates and can return an aggregate, entity, or value object.  

Repositories 

Repositories control the middle and the end of the aggregate lifecycle. They persist in aggregates and solve problems with data storage. 

Services

A service is a stateless class between entities and value objects but is not connected to either. 

Events

Aggregates can publish events that happen in the core domain. Developers can use events to track changes to the state of an application.

Strategic Design

The Strategic design model organizes design around context instead of functions. We can break the strategic design into three components:

Domain Model 

As previously mentioned, this is an object-oriented way to deal with domain logic. Domain models can solve business problems and improve application development.  

Ubiquitous Language

This is the language that everyone involved in domain-driven design (business team members, development teams, domain experts, etc.) understands.

When different teams use different languages, it can influence application behavior and software architecture, resulting in longer development times and software vulnerabilities. 

Bounded Context

Bounded context refers to the boundary within a domain where teams can define and implement a domain model.

These contexts are not always isolated from each other.

Why Domain-Driven Design is important

Domain-driven design is important for many reasons:

• It improves communication. Teams that use a ubiquitous language can remove communication silos and improve application behavior and architecture, which makes it easier to develop and implement applications. When everyone uses the same language, teams can improve productivity and achieve long-term business goals rather than just focus on how a particular software application works.
• It focuses on users. While other software and product development approaches concentrate on functions, implementing domain-driven design is all about satisfying end users. This approach keeps the domain at the forefront of the design process to fulfill the needs of the business using an application.
• It reduces complexities. Domains can be complicated, and making changes to business domain rules can impact the functionality of an application in development. Domain-driven design methodology solves the problem of complex domains with its layered architecture, where each layer is dependent on the layer below. Eric Evans recommends four layers for domain-driven design: A user interface layer, a domain layer, an application layer, and an infrastructure layer. 
• It aligns business and development. The Domain-driven design aligns business processes with development objectives. That reduces the risk of errors and results in more successful software development outcomes. Businesses and developers can define the procedures and functions of a domain before working on it and benefit from collaboration. 
• It improves coding. As well as benefiting from a ubiquitous language, developers can get more value from coding when using the domain-driven design approach. Teams can create coding best practices that enhance software development projects and create better products that meet the needs of the business they work for. 

Domain-driven design isn't something that most businesses can do themselves. It requires advanced domain expertise and knowledge of domain models and logic.

Working with a company that delivers world-class software engineering and development can help your organizations create applications that solve real-world business needs.

Conclusion

Domain-driven design is a software development concept about designing applications for business value.

There are two approaches to domain-driven design, and understanding the principles of each can encourage developers to create software that influences business-critical decisions.

While this design concept requires advanced domain expertise, it can improve communication, reduce domain complexities, and focuses on end-users.

Adservio works with organizations in assisting them in implementing a domain-driven approach, improving software delivery, and streamlining operations toward better solving the needs of end-users.