Introduction to Domain Driven Design (DDD) - Basic Concepts and Rudiments of Practice

1. Introduction

In this article, I will explain the basic concepts and initial practices of Domain-Driven Design (DDD) as an output of what I have learned. My interest in DDD was sparked by the following reasons:

1. The product I was responsible for adopted DDD.
2. I struggled due to a lack of domain knowledge.

2. Basic Concepts of DDD

DDD is a method of software development that centers around domain knowledge in design. Below are the key concepts.

2.1 Domain

The domain refers to the area that the system deals with. For example, in an e-commerce site, this includes products, purchase history, orders, etc.

2.2 Bounded Contexts

Bounded Contexts are concepts that divide a part of the domain into a cohesive unit. For example, in an e-commerce site, it might be possible to separate "inventory management" and "sales management" into different contexts. By dividing the context, different parts of the design can be made independent, improving the clarity of the code.

2.3 Main Patterns in DDD

• Entity: An object that can be uniquely identified within the domain. For example, a "customer" on an e-commerce site is an entity identified by an ID.
• ValueObject: Unlike entities, ValueObjects are not identified uniquely. They are immutable, and examples include addresses and prices.
• Service: Objects that handle the business logic of the domain, operating across multiple entities or aggregates. Services are divided into two types:
  • Domain Service: Provides business logic across multiple entities or aggregates, maintaining consistency of business rules within the domain. For example, an "Order Service" would handle business logic related to orders.
  • Application Service: Coordinates the overall business processes of the system based on user use cases, working with domain services and repositories. For example, an "Order Processing Application Service" would manage the entire process related to orders (creation, confirmation, stock reservation, payment processing, shipping arrangements, etc.).
• Repository: Objects responsible for storing and reconstructing data from entities or aggregates. For example, a "Customer Repository" stores customer entities and retrieves them when needed.
• Factory: Specializes in creating objects, particularly useful when the creation process varies under certain conditions or the objects are complex. Using factories can hide the details of creation, enhancing code reusability and testability.
• Aggregate: Groups entities and ValueObjects into a single unit that holds a set of operations and rules. For example, an "Order Aggregate" would include customer entities and product ValueObjects, providing operations related to orders.

These patterns can be categorized as follows:

1. Representing Knowledge
   • Entity
   • ValueObject
   • Domain Service
   • Aggregate
2. Realizing Applications
   • Repository
   • Application Service
   • Factory

3. Practical Examples of DDD

Domain modeling is a design process that organizes business logic and implements business rules. First, the entire domain is divided into bounded contexts, and within each area, entities, ValueObjects, and relationships between entities are defined. This enhances the integrity and reusability of the system, efficiently applying specific business rules. Examples of domain modeling are shown below.

3.1 Customer Context Modeling

In the "Customer" context, a "Customer" entity and a "Name" ValueObject are defined. The customer entity includes attributes such as name, email address, and address, and the name ValueObject includes first and last name attributes.

3.2 Handling Price Fluctuations

On an e-commerce site, product prices can fluctuate due to sales and other promotions. By equipping the price ValueObject with attributes for "regular price" and "discount price," as well as "discount rate," it is possible to accurately manage prices during sales periods. The price change service implements price switches based on specific conditions (sale periods, promotions for certain customers, etc.).

3.3 Order Returns

To handle order returns, domain services and repositories are utilized to implement the return process. The order service adds a "return" function, defining the business logic for how to return products when returns occur. The following is an example of the return process:

1. Saving Return Reasons and Product Information The return request includes the reason for return and the information of the returned product (product name, price, quantity, etc.), which is stored in the repository. This allows tracking which products were returned for what reasons, aiding in later analysis and improvements.
2. Updating Inventory Returned products are restocked, and the inventory is updated as part of the return process. This ensures that the latest inventory information is maintained, and accurate stock levels are known across other orders and inventory management systems.
3. Notifying Customers After the return process is completed, customers are notified. Notifications include confirmation of return approval, receipt of returned

goods, and progress of the refund process, helping customers understand at what stage their return is.

4. Conclusion

Studying DDD has made me realize that it is possible to organize complex business logic and achieve high-reusability designs. The concept of bounded contexts, in particular, is very important for clearly segmenting the entire system and focusing on domain-centric design. While there is still much to learn in practice, this study has helped me re-recognize the importance of domain knowledge in system design. I intend to continue learning and utilize the concepts of DDD in future projects to create more valuable software.