General

1. DDD là gì? Hiểu đơn giản trong 1 phút¶

Hãy quên đi các định nghĩa phức tạp. Hãy tưởng tượng:

Cách làm truyền thống: Bạn nhận yêu cầu từ bộ phận kinh doanh (ví dụ: "Xây dựng tính năng quản lý đơn hàng"). Bạn, với tư cách là lập trình viên, bắt đầu nghĩ ngay đến database table, API endpoint, class, function...
Cách làm theo DDD: Bạn ngồi lại với chuyên gia nghiệp vụ (domain expert). Thay vì nói về table, bạn nói về "Đơn Hàng" (Order). "Đơn Hàng" có gì? Nó có thể được "Xác nhận" (Confirm), "Hủy" (Cancel). Nó bao gồm các "Mặt Hàng" (LineItem). Toàn bộ cuộc nói chuyện của bạn xoay quanh các khái niệm và quy trình kinh doanh.

DDD là một phương pháp tiếp cận phát triển phần mềm mà ở đó, cấu trúc và ngôn ngữ của code phải khớp với mô hình kinh doanh.

Nói cách khác: Code của bạn chính là tấm gương phản chiếu nghiệp vụ.

2. Các Thành Tố Cốt Lõi Của DDD¶

Để làm được điều trên, DDD có vài khái niệm "xương sống" bạn cần nắm:

Ngôn Ngữ Chung (Ubiquitous Language)¶

Đây là khái niệm quan trọng NHẤT.

Là gì? Là một bộ thuật ngữ chung, duy nhất mà cả đội phát triển (dev, QA) và chuyên gia nghiệp vụ (business analyst, product manager) đều sử dụng để mô tả hệ thống.
Ví dụ: Nếu nghiệp vụ gọi một khách hàng tiềm năng là "Prospect", thì trong code của bạn, tên class, variable, database table cũng phải là Prospect, chứ không phải Customer hay Lead. Sự thống nhất này loại bỏ hoàn toàn sự hiểu lầm.

Bối Cảnh Giới Hạn (Bounded Context)¶

Một nghiệp vụ lớn thường được chia thành nhiều phần nhỏ hơn. Bounded Context là ranh giới logic để phân chia chúng.

Là gì? Là một đường biên rõ ràng, nơi một mô hình nghiệp vụ (domain model) cụ thể được áp dụng. Bên trong đường biên này, mọi thuật ngữ có một ý nghĩa duy nhất.
Ví dụ trực quan: Trong một trang thương mại điện tử, khái niệm "Sản phẩm" (Product) có ý nghĩa khác nhau ở các bộ phận:
- Trong Bối cảnh Bán Hàng (Sales Context): "Sản phẩm" có các thuộc tính như Giá Bán, Khuyến Mãi.
- Trong Bối cảnh Kho Vận (Warehouse Context): "Sản phẩm" lại có các thuộc tính như Vị Trí Kệ, Trọng Lượng, Kích Thước.
- Trong Bối cảnh Hỗ Trợ (Support Context): "Sản phẩm" có thể có Hướng Dẫn Sử Dụng, Chính Sách Bảo Hành.

Thay vì tạo một class Product khổng lồ chứa tất cả mọi thứ, DDD chia nó thành 3 class Product nhỏ hơn, mỗi cái nằm trong Bounded Context của riêng nó.

Cụm (Aggregate)¶

Đây là cách chúng ta đảm bảo tính toàn vẹn dữ liệu theo quy tắc nghiệp vụ.

Là gì? Là một nhóm các đối tượng nghiệp vụ (Entities, Value Objects) được xem như một thể thống nhất. Mọi tương tác từ bên ngoài phải thông qua một đối tượng đại diện duy nhất gọi là Aggregate Root.
Ví dụ kinh điển: Một "Đơn Hàng" (Order) là một Aggregate Root. Nó chứa danh sách các "Mặt Hàng" (OrderItem).
- Bạn không thể tự ý thêm một OrderItem vào database.
- Bạn phải thông qua đối tượng Order và gọi phương thức Order.AddItem(...).
- Bên trong phương thức này, Order sẽ kiểm tra các quy tắc nghiệp vụ (ví dụ: "tổng giá trị đơn hàng không vượt quá 100 triệu", "không thể thêm sản phẩm đã hết hàng").

Điều này đảm bảo rằng trạng thái của "Đơn Hàng" luôn hợp lệ.

3. Khi Nào Nên "Rút Gươm" DDD?¶

DDD không dành cho tất cả mọi dự án. Hãy dùng nó khi:

Nghiệp vụ phức tạp (Complex Business Domain): Đây là lý do lớn nhất. Dự án của bạn có nhiều quy tắc, quy trình lồng vào nhau mà chỉ chuyên gia mới hiểu rõ. Ví dụ: hệ thống ngân hàng, bảo hiểm, logistics, sàn thương mại điện tử lớn.
Dự án dài hạn, cần bảo trì và mở rộng: DDD giúp code dễ hiểu và dễ thay đổi khi nghiệp vụ tiến hóa, giảm chi phí bảo trì trong tương lai.
Cần sự hợp tác chặt chẽ giữa đội kỹ thuật và nghiệp vụ: Khi thành công của dự án phụ thuộc vào việc team dev hiểu đúng ý của team business.

Khi nào KHÔNG nên dùng?

Các ứng dụng CRUD đơn giản: Ví dụ một blog cá nhân, một trang giới thiệu sản phẩm đơn thuần. Áp dụng DDD ở đây là "dùng dao mổ trâu để giết gà", gây phức tạp không cần thiết.
Dự án có nghiệp vụ không rõ ràng, thay đổi liên tục: DDD cần một domain tương đối ổn định để mô hình hóa.
Dự án ngắn hạn, làm xong rồi bỏ.

4. Ưu và Nhược Điểm: Cái Giá Của Sức Mạnh¶

Ưu Điểm (Pros)	Nhược Điểm (Cons)
Giao tiếp hiệu quả: Mọi người dùng chung một ngôn ngữ, giảm hiểu lầm.	Đường cong học tập cao: Đòi hỏi cả team phải hiểu và tuân theo các nguyên tắc.
Code phản ánh đúng nghiệp vụ: Dễ hiểu, dễ bảo trì cho người mới.	Phức tạp ban đầu: Cần nhiều thời gian hơn cho việc phân tích và thiết kế.
Tính linh hoạt và khả năng mở rộng: Dễ dàng thêm/sửa tính năng theo nghiệp vụ.	Không phù hợp cho dự án nhỏ: Gây ra sự cồng kềnh không cần thiết (over-engineering).
Tập trung vào giá trị cốt lõi: Giúp team tập trung giải quyết vấn đề kinh doanh.	Yêu cầu có chuyên gia nghiệp vụ: Cần có người thực sự hiểu domain để hợp tác.

5. Những Lưu Ý Vàng Khi Áp Dụng¶

Chuyên gia nghiệp vụ là VUA: Thành công của DDD phụ thuộc 80% vào việc bạn có thể trao đổi và học hỏi từ họ. Hãy dành thời gian nói chuyện với họ, đừng chỉ ngồi trong phòng code.
Bắt đầu từ Bounded Context: Đừng cố gắng áp dụng DDD cho toàn bộ hệ thống ngay lập tức. Hãy xác định các Bounded Context và chọn một context cốt lõi, phức tạp nhất để bắt đầu.
Ngôn Ngữ Chung là một quá trình: Nó không có ngay từ đầu. Nó sẽ được tinh chỉnh và hoàn thiện dần qua các cuộc thảo luận. Hãy ghi nó ra một nơi mọi người đều thấy (wiki, confluence).
Đừng lạm dụng: Không phải mọi thứ trong Bounded Context đều cần là Aggregate. Hãy giữ cho mô hình đơn giản nhất có thể.

6. Kết Luận: DDD Dành Cho Ai?¶

DDD không phải là một framework hay một công nghệ, nó là một triết lý, một tư duy. Nó dành cho các đội ngũ muốn xây dựng những phần mềm chất lượng cao, bền vững theo thời gian bằng cách đặt nghiệp vụ kinh doanh vào vị trí trung tâm.

Nếu bạn đang xây dựng một ứng dụng đơn giản, hãy dùng các kiến trúc thông thường. Nhưng nếu bạn đang đối mặt với một "con quái vật" nghiệp vụ phức tạp, DDD chính là vũ khí bạn cần để thuần hóa nó.

7. Cấu trúc dự án¶

src/
 ├── domain/                     # Nơi chứa logic nghiệp vụ
 │    ├── order/
 │    │     ├── Order.ts         # Aggregate Root
 │    │     ├── OrderItem.ts     # Entity
 │    │     ├── ValueObjects/
 │    │     │     ├── Money.ts
 │    │     │     └── Quantity.ts
 │    │     └── OrderRepository.ts  # Interface
 │    └── customer/
 │          └── Customer.ts
 │
 ├── application/                # Dùng cho use case
 │    └── OrderService.ts
 │
 ├── infrastructure/             # Triển khai kỹ thuật
 │    ├── persistence/
 │    │     └── OrderRepositoryImpl.ts
 │    ├── http/
 │    │     └── OrderController.ts
 │    └── db/
 │          └── migrations.sql
 │
 └── shared/
      └── utils.ts

Workflow xử lý request

flowchart TD
    A["User gửi yêu cầu tạo đơn hàng"] --> B["OrderController API"]
    B --> C["OrderService - Application Layer"]
    C --> D["Order (Aggregate Root)"]
    D -->|Kiểm tra luật nghiệp vụ| E["OrderItem, Money, Quantity"]
    D --> F["OrderRepository (Interface)"]
    F --> G["OrderRepositoryImpl (Infrastructure)"]
    G --> H[("Database")]

Class Diagram

classDiagram
    class Order {
        -id: OrderId
        -items: List~OrderItem~
        +AddItem(item)
        +Confirm()
        +Cancel()
    }

    class OrderItem {
        -productId: ProductId
        -quantity: Quantity
        -price: Money
    }

    class Quantity {
        -value: int
    }

    class Money {
        -amount: decimal
        -currency: string
    }

    Order --> "1..*" OrderItem
    Order --> Quantity
    Order --> Money

Nguyên tắc vàng:

Domain không biết gì về Database hay HTTP
Application điều phối Domain và Infrastructure
Infrastructure implement các interface mà Domain định nghĩa

Khi Nào Nên Dùng DDD?

NÊN Dùng Khi:

Nghiệp vụ phức tạp: Banking, Insurance, E-commerce lớn

Nhiều quy tắc: "Nếu A thì B, nhưng nếu C thì D, trừ trường hợp E..."

Team lớn: Cần phân chia rõ ràng trách nhiệm

Dự án lâu dài: Cần maintain và upgrade nhiều năm

KHÔNG Nên Dùng Khi:

CRUD đơn giản: Blog cá nhân, website giới thiệu

Prototype/MVP: Cần làm nhanh để test ý tưởng

Team nhỏ (1-2 người): Overhead quá lớn

Nghiệp vụ không rõ ràng: Chưa biết làm gì, requirements thay đổi liên tục