1 What is DDD?

DDD is domain-driven design, which was proposed by Eric Evans in 2003, 17 years ago.

2 Why is DDD needed

As software becomes more and more complex, it is common to see a large amount of business logic piled up in a giant class in actual development, and the reusability and extensibility of the code cannot be guaranteed. In order to solve this problem, DDD proposed a clear concept of hierarchical architecture and domain objects, which brought object-oriented analysis and design into a new stage and greatly promoted enterprise software development.

2.1 How do POP, OOP and DDD solve problems

Procedural programming (POP), the first step in approaching requirements is to consider breaking them down into functions from the top down. In this process, specific organization methods such as layering and modularization are considered to decompose the complexity of software. POP works well when software complexity is low.

Object oriented programming (OOP), the first step to consider the need to decompose into an object, and then each object to add a method and attributes, procedures through a variety of objects between the call and collaboration, so as to achieve the function of computer software. OOP, like many engineering approaches, was originally designed as a way of dealing with software complexity.

Domain driven design (DDD), the first step to consider the need to decompose into a problem domain, and then the decomposition of each problem domain into an object, the program through the call and collaboration between various problem domains, so as to achieve the function of computer software. DDD is a set of effective ways to solve complex medium and large software, has become the mainstream.

2.2 Characteristics of POP, OOP and DDD

POP, no boundaries, small software complexity is suitable, such as “building a house”.

OOP, which is bounded by “objects”, is useful in software complexity, such as “cover cells”.

DDD, with “problem domain” as the boundary, is suitable for software complexity, such as “build city”.

3 Layered architecture and components of DDD

3.1 Layered Architecture

The whole architecture is divided into four layers, the core of which is Domain layer. All business logic should be realized in Domain layer, as described below:

The user interface/presentation layer is responsible for presenting information to the user and interpreting user commands.

The application layer, a very thin layer, coordinates the activities of the application. It contains no business logic. It does not retain the state of the business object, but it retains the progress state of the application task.

The domain layer, which contains information about the domain. This is the heart of business software. The state of the business objects is retained here, and persistence of the business objects and their state is delegated to the infrastructure layer.

Infrastructure layer, this layer as other layers of support inventory in. It provides the communication between layers, implements the persistence of business objects, and supports the user interface layer.

3.2 Constituent Elements

An Entity that has a unique ID, can be persisted, has business logic, and corresponds to real-world business objects.

A Value Object does not have a unique ID and is described by the attributes of the Object. It is usually a temporary Object in memory and can be used to pass parameters or provide supplementary descriptions for entities.

Domain Service provides operable interfaces for the superstructure, schedules and encapsulates Domain objects, and provides various forms of services externally.

The Aggregate Root belongs to the entity object. The Aggregate Root has a globally unique ID, while the entity has a unique local ID only within the Aggregate. The value object has no unique ID

Factories are used to create aggregate roots. IOC containers are used in architectural practice to implement Factories.

A Repository encapsulates the infrastructure to provide query and persistent aggregation operations.

4 summary

In this article, we learned that DDD was created to solve software complexity. The biggest difference from OOP is the way of demarcating boundaries, so DDD itself does not feel complicated to master. DDD is actually the study of where to put ifELSE statements containing business logic.