What is Domain Driven Design (DDD)?
Domain-Driven Design (DDD) is a software development approach used to solve complex business problems more effectively. This article explains the core concepts, principles, architectural models, and advantages of DDD in a simple and understandable way.
Domain Driven Design (DDD) is an approach used for developing software applications. DDD aims to create software solutions that reflect business domain needs by acting as a bridge between the technical side and the business side.
Domain Driven Design provides a set of practices for collaboratively building software from the perspective of the target business, its domain, and its problems.
DDD reminds us that software developers are not the only people involved in software development. Domain experts, who have deep knowledge of the domain where the software is built, bring important insights about the problems being solved.
What is a Domain?
A “domain” is the specific business area or problem space that an application aims to solve. For example, banking, e-commerce, healthcare systems, or logistics can each be considered a domain. In the DDD approach, having a deep understanding of the domain is very important because solutions should be designed according to that context.
Core Principles of the DDD Approach:
Ubiquitous Language:
In the DDD approach, domain experts and software developers should use the same language. This is important for eliminating confusion and misunderstandings. If the parties want to communicate effectively, they should speak the same language instead of relying on translations.
In the DDD approach, domain experts and software developers should use the same language. This is important for eliminating confusion and misunderstandings. If the parties want to communicate effectively, they should speak the same language instead of relying on translations.
Knowledge sharing in a software project:
Photo: Vlad Khononov — Learning Domain Driven Design
Subdomains:
To make the domain easier and more efficient to manage, it is divided into different subdomains. Subdomains should interact with each other in order for the company to achieve its goals.
To make the domain easier and more efficient to manage, it is divided into different subdomains. Subdomains should interact with each other in order for the company to achieve its goals.
Types of subdomains:
Core Subdomains:
Core subdomains are the ones that other companies either do not implement or implement differently. These subdomains provide the company with a competitive advantage.
Core subdomains are the ones that other companies either do not implement or implement differently. These subdomains provide the company with a competitive advantage.
Generic Subdomains:
Generic subdomains are the ones implemented in the same way by all companies. In a sense, they are “solved problems.” These subdomains do not provide any competitive advantage to the company.
Generic subdomains are the ones implemented in the same way by all companies. In a sense, they are “solved problems.” These subdomains do not provide any competitive advantage to the company.
Supporting Subdomains:
Supporting subdomains are the subdomains that support the company’s business operations. Like generic subdomains, they do not provide any competitive advantage to the company.
Supporting subdomains are the subdomains that support the company’s business operations. Like generic subdomains, they do not provide any competitive advantage to the company.
Bounded Context:
A bounded context is a limited part of a software system that covers a specific business area. This context makes it easier to understand and manage the business domain. Each bounded context has its own unique components.
A bounded context is a limited part of a software system that covers a specific business area. This context makes it easier to understand and manage the business domain. Each bounded context has its own unique components.
Entities and Value Objects:
Entity:
Entities are objects that have a unique identifier. For example, a customer (identified by an ID) or any product in a marketplace.
Entities are objects that have a unique identifier. For example, a customer (identified by an ID) or any product in a marketplace.
Value Object:
Value objects are objects that do not require an identity. For example, a payment amount or an address. These components usually store the attributes or properties of entities.
Value objects are objects that do not require an identity. For example, a payment amount or an address. These components usually store the attributes or properties of entities.
class Product:
"""Entity representing a product."""
def ``init``(self, name: ProductName, price: Price, category: Category):
self.id = str() # Unique identifier for the entity
self.name = name
self.price = price
self.category = categoryHere, we can say that the product is an Entity because it has a unique ID. Variables such as name, price, and category are considered Value Objects.
Domain Event
These are important events that occur within the system. For example, events such as “Customer placed an order.” The purpose of Domain Events is to describe what happens in the business domain and provide all the necessary information related to the event.
Aggregates:
Aggregates are controlled groups where Entities and Value Objects come together as a single unit.
Photo: Vlad Khononov — Learning Domain Driven Design
The hierarchy includes both Value Objects and Entities, and all of them belong to the same Aggregate.
Aggregate Root:
An Aggregate Root is a component that represents a unified and meaningful concept within the domain, such as an order, customer, or product. It serves as the entry point for any interaction with the aggregate, which is a collection of objects associated with it and governed by its rules.
An Aggregate Root is a component that represents a unified and meaningful concept within the domain, such as an order, customer, or product. It serves as the entry point for any interaction with the aggregate, which is a collection of objects associated with it and governed by its rules.
Architecture Model in DDD
The DDD approach is often built together with models such as Hexagonal Architecture, Layered Architecture, or Onion Architecture. In these models, the domain layer is placed at the center, and the other layers serve the needs of the domain.
Layered Architecture
Hexagonal Architecture
Advantages of DDD:
- Simplifying Complex Problems:
The Domain-Driven Design (DDD) approach makes it possible to divide complex business problems into smaller, more manageable, and understandable parts. With this approach, each domain problem is treated as a specific area of focus. This simplifies both the development of the software and its ongoing maintenance and support. - Focusing on Business Needs:
One of the core principles of DDD is focusing on business needs rather than purely technical solutions. This approach encourages developers and designers to better understand business processes and create solutions that align with these requirements. As a result, systems become more purposeful, effective, and closely connected to the overall goals of the project. - Effective Communication Within the Team:
DDD promotes the creation of a ubiquitous language that is aligned with the domain area. This common language helps technical teams understand each other more effectively. By simplifying technical terminology and adapting it to the business context, misunderstandings between team members are minimized, and collaboration throughout the project becomes much easier.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article