Thiết kế hướng miền (DDD, Domain-Driven Design)

1. Tổng quan

Thiết kế hướng miền (DDD) là cách tiếp cận thiết kế đặt trọng tâm của phần mềm vào vấn đề và mô hình của miền nghiệp vụ thay vì framework kỹ thuật, trong đó chuyên gia miền và nhà phát triển liên tục phát triển một mô hình dùng chung qua nhiều vòng lặp.

Hệ thống doanh nghiệp không chỉ dừng ở các chương trình nhập và tra cứu dữ liệu đơn giản, mà còn kết hợp các quy tắc nghiệp vụ như sản phẩm, hợp đồng, quyết toán, giao hàng, quy định pháp lý để đưa ra quyết định. Nghiệp vụ càng phức tạp thì cùng một từ lại được các bộ phận dùng với nghĩa khác nhau, và thay đổi trên một màn hình có thể gây ảnh hưởng dây chuyền đến chính sách của nhiều hệ thống và tổ chức. Khi đó, cách làm tạo bảng cơ sở dữ liệu trước rồi gắn thêm màn hình dịch vụ có thể xây dựng chức năng nhanh, nhưng khó giải thích quyền sở hữu quy tắc và ranh giới thay đổi. DDD làm lộ rõ sự phức tạp đó thông qua mô hình miền, ngôn ngữ, ranh giới và bất biến (invariant), từ đó nâng cao tính nhất quán giữa thiết kế và hiện thực.

Cốt lõi của DDD không nằm ở việc áp dụng máy móc một framework hay mẫu lớp cụ thể. Nhà phát triển lắng nghe cách diễn đạt của chuyên gia miền, mô hình hóa các khái niệm ứng viên, và nếu mô hình không giải thích được quyết định nghiệp vụ thực tế thì tiếp tục đặt câu hỏi và chỉnh sửa. Vì vậy, DDD là một lối tư duy kết nối phân tích, thiết kế, hiện thực, kiểm thử và vận hành, không được thu hẹp thành kỹ thuật tái cấu trúc (refactoring) riêng của đội kỹ thuật.

Miền (domain) là lĩnh vực nghiệp vụ mà hệ thống cần giải quyết, còn miền con (subdomain) là phần được chia ra từ lĩnh vực đó theo mục đích và trách nhiệm. Miền con cốt lõi (core) là nguồn gốc của năng lực cạnh tranh và sự khác biệt, nên có giá trị cao khi phát triển bằng năng lực nội bộ. Miền con hỗ trợ (supporting) cần thiết cho nghiệp vụ nhưng tính khác biệt tương đối thấp, nên có thể hiện thực bằng sản phẩm chuẩn hoặc dịch vụ nội bộ đơn giản. Miền con chung (generic) là các chức năng mà hầu hết tổ chức đều cần, như mua sắm, xác thực, thư điện tử; việc tận dụng gói phần mềm hoặc dịch vụ bên ngoài có thể hợp lý hơn.

Việc có cần DDD hay không được đánh giá dựa trên độ phức tạp của quy tắc và tần suất thay đổi hơn là quy mô hệ thống. Đưa một mô hình miền nặng nề vào hệ thống tra cứu có quy tắc đơn giản chỉ có thể làm tăng thời gian phát triển và độ phức tạp vận hành. Ngược lại, với hệ thống đan xen giảm giá, tồn kho, quyết toán, phân quyền và ngoại lệ pháp lý, nếu không có mô hình thì các quy tắc ngầm trong mã và dữ liệu sẽ nhanh chóng tích tụ thành nợ kỹ thuật. Kỹ sư chuyên nghiệp (Professional Engineer) phải quyết định áp dụng DDD không theo trào lưu mà từ góc độ độ phức tạp miền, chi phí thay đổi, cơ cấu tổ chức và yêu cầu tích hợp.

2. Sơ đồ khái niệm tổng thể và nguyên lý thiết kế của DDD

DDD trước hết xác định các ranh giới lớn bằng thiết kế chiến lược, sau đó cụ thể hóa mô hình và trách nhiệm bên trong từng ranh giới bằng thiết kế chiến thuật. Hai giai đoạn này tách biệt nhưng phản hồi lẫn nhau. Nếu ranh giới chiến lược sai thì dù viết các mẫu chiến thuật tinh xảo đến đâu, sự kết dính giữa các dịch vụ và chi phí chuyển đổi vẫn không giảm.

flowchart LR
    A[Miền nghiệp vụ] --> B[Nhận diện miền con]
    B --> C{Đánh giá tính cốt lõi, độ phức tạp}
    C -->|Cốt lõi| D[Miền con cốt lõi]
    C -->|Hỗ trợ| E[Miền con hỗ trợ]
    C -->|Chung| F[Miền con chung]
    D --> G[Ranh giới Bounded Context]
    E --> G
    F --> G
    G --> H[Context map và hợp đồng tích hợp]
    H --> I[Mô hình miền, ngôn ngữ chung]
    I --> J[Aggregate, Entity, Value Object]
    J --> K[Domain Service, Event, Repository]

Phân rã miền không phải là sao chép sơ đồ phòng ban hiện tại của tổ chức. Cần xác nhận rằng từ "khách hàng" có thể là người mua tiềm năng trong bán hàng, chủ thể mua trong đơn hàng, và bên nợ trong quản lý công nợ, rồi xác định ranh giới dựa trên quy tắc và trách nhiệm của từng nghiệp vụ. Nếu cố thống nhất cùng một thuật ngữ thành một đối tượng khổng lồ trong mọi hệ thống sẽ phát sinh phụ thuộc không cần thiết, nên việc chấp nhận khác biệt ý nghĩa theo ngữ cảnh lại giúp tăng tính nhất quán.

Ngôn ngữ chung (ubiquitous language) là ngôn ngữ mà chuyên gia miền và nhà phát triển cùng sử dụng trong mô hình, mã nguồn, kiểm thử và tài liệu. Nếu trong cuộc họp nói "xác nhận đặt chỗ" nhưng trong mã lại hiện thực bằng createOrder, sẽ xảy ra mất mát khi chuyển đổi giữa ngôn ngữ và mô hình. Bảng thuật ngữ chỉ là điểm khởi đầu; hiệu quả chỉ thực sự xuất hiện khi thuộc tính, trạng thái, hành vi và cả thông báo lỗi của mô hình thực tế đều giữ cùng một ý nghĩa.

Mô hình miền không phải là tập hợp các cấu trúc dữ liệu mà là cấu trúc của quy tắc nghiệp vụ và quyết định. Ví dụ, tổng tiền đơn hàng không đơn thuần là cộng giá sản phẩm, mà có thể là kết quả phản ánh thứ tự áp dụng giảm giá, làm tròn thuế và điều kiện giao hàng. Nếu quy tắc tính toán này bị rải rác trong controller màn hình hay SQL xử lý lô, khi thay đổi sẽ dễ bị sót, nên cần đặt chủ sở hữu quy tắc và bất biến vào trong mô hình.

Bảng dưới đây là công cụ bổ trợ để đối chiếu nhanh các khái niệm chính của DDD. Mỗi khái niệm cần được hiểu như các mối quan hệ nối kết ý nghĩa và trách nhiệm của mô hình, chứ không phải một danh sách kiểm tra độc lập.

Khái niệm	Câu hỏi cốt lõi	Trách nhiệm chính	Hiểu lầm phổ biến
Miền (Domain)	Giải quyết vấn đề nghiệp vụ nào?	Xác định phạm vi và mục đích của vấn đề	Coi chính cơ sở dữ liệu là miền
Miền con (Subdomain)	Đâu là một năng lực nghiệp vụ trọn vẹn?	Phân biệt vùng cốt lõi, hỗ trợ, chung	Sao chép nguyên sơ đồ phòng ban
Bounded Context	Mô hình và ngôn ngữ nào có hiệu lực?	Xác định ranh giới áp dụng mô hình và hợp đồng	Mọi ngữ cảnh dùng chung cùng một đối tượng
Entity	Có cần theo dõi cùng một đối tượng theo thời gian không?	Quản lý định danh và vòng đời	Biến mọi bảng thành Entity
Value Object	Bản thân giá trị có ý nghĩa và không cần định danh?	Đóng gói giá trị bất biến và kiểm tra hợp lệ	Truyền chuỗi, số một cách tùy tiện
Aggregate	Những thay đổi nào gộp thành một ranh giới nhất quán?	Bảo vệ bất biến và ranh giới giao dịch	Nhét mọi đối tượng vào một root lớn
Domain Event	Sự kiện nghiệp vụ nào đã xảy ra?	Truyền sự kiện giữa các ngữ cảnh	Đồng nhất với thông điệp log đơn thuần

Nguyên lý của DDD không phải là "biến mọi thứ thành đối tượng". Cốt lõi của mô hình hóa là phân biệt quy tắc nào phải được thỏa mãn đồng thời ngay lập tức và thông tin nào có thể phản ánh sau thông qua sự kiện. Sự phân biệt này quyết định cả phạm vi giao dịch, cấu trúc lưu trữ, hợp đồng API và cách khôi phục sự cố.

3. Thiết kế chiến lược: miền con và Bounded Context

3.1 Phân loại miền con và thứ tự ưu tiên đầu tư

Phân loại miền con nối kết chiến lược kinh doanh với các quyết định kiến trúc. Miền con cốt lõi là năng lực mà khách hàng nhận biết để phân biệt với doanh nghiệp khác, thường là vùng có độ khó hiện thực cao và quy tắc thay đổi thường xuyên. Vì vậy, ở vùng cốt lõi cần bố trí chuyên gia miền và nhà phát triển lành nghề, đồng thời đầu tư vào chất lượng mô hình và kiểm thử.

Miền con hỗ trợ trợ giúp nghiệp vụ cốt lõi nhưng bản thân có lợi thế cạnh tranh thấp. Ví dụ, nếu tối ưu hóa sản xuất là cốt lõi của doanh nghiệp sản xuất, thì nhân sự chung và phê duyệt điện tử có thể được xếp vào vùng hỗ trợ hoặc chung. Không nhất thiết phải thuê ngoài vùng hỗ trợ; cần so sánh đồng thời chi phí tích hợp, chủ quyền dữ liệu, bảo mật và yêu cầu thay đổi để quyết định.

Miền con chung là năng lực mà nhiều tổ chức giải quyết theo cách tương tự. Nếu tự xây dựng mô hình riêng cho vùng này, chi phí bảo trì có thể tăng không cần thiết, nên hãy dùng giải pháp chuẩn và tập trung năng lực vào vùng tạo khác biệt. Tuy nhiên, ngay cả khi đưa gói phần mềm vào, vẫn phải quản lý khác biệt giữa thuật ngữ nội bộ và thuật ngữ bên ngoài ở lớp chuyển đổi để mô hình cốt lõi không bị ô nhiễm.

Danh mục kinh doanh và phân loại miền con không phải là chân lý cố định. Tùy theo thay đổi quy định hoặc chiến lược kinh doanh, chức năng chung có thể trở thành năng lực cốt lõi, và thay đổi về giá hay mức độ phụ thuộc của nền tảng bên ngoài cũng là yếu tố cần đánh giá lại. Kết quả phân loại cần ghi lại không chỉ mức độ quan trọng mà cả tần suất thay đổi, chi phí thất bại, chuyên môn có thể huy động và khả năng thay thế bằng bên ngoài.

3.2 Bounded Context và ranh giới mô hình

Bounded Context là ranh giới tường minh trong đó một mô hình miền và ngôn ngữ chung cụ thể có hiệu lực. Bên trong ranh giới, ý nghĩa và bất biến của "khách hàng", "đơn hàng", "trạng thái" được giữ nhất quán, nhưng khi vượt ranh giới thì chỉ trao đổi thông tin cần thiết qua API, sự kiện và bộ chuyển đổi. Nhờ đó, hiện thực bên trong của mô hình được che giấu và mỗi đội có thể thay đổi quy tắc nghiệp vụ của mình một cách độc lập.

Ranh giới ngữ cảnh có thể trùng với ranh giới lược đồ cơ sở dữ liệu nhưng không phải lúc nào cũng vậy. Một ngữ cảnh có thể dùng nhiều kho lưu trữ, và ban đầu có thể tách lược đồ logic trong cùng một cơ sở dữ liệu rồi dần dần tách vật lý. Điều quan trọng không phải là vị trí lưu trữ mà là làm rõ quyền sở hữu mô hình và hợp đồng thay đổi.

Khi xác định ranh giới, cần xem xét đồng thời ý nghĩa thuật ngữ, lý do thay đổi, tính nhất quán giao dịch, trách nhiệm của đội, liên kết bên ngoài và cấp độ bảo mật. Các chức năng có cùng lý do thay đổi nên đặt gần nhau, còn các chức năng thay đổi vì lý do khác nhau thì không nên gộp một cách không cần thiết. Nếu quyết định số lượng microservice trước rồi mới ép miền vào cho vừa, nguy cơ trở thành "distributed monolith" (khối nguyên khối phân tán) sẽ tăng.

flowchart TB
    subgraph Sales[Ngữ cảnh bán hàng]
        S1[Báo giá bán hàng]
        S2[Đơn bán hàng]
        S3[Ý định mua của khách hàng]
    end
    subgraph Fulfillment[Ngữ cảnh thực hiện đơn]
        F1[Lệnh xuất kho]
        F2[Đặt giữ tồn kho]
        F3[Trạng thái giao hàng]
    end
    subgraph Billing[Ngữ cảnh quyết toán]
        B1[Hóa đơn]
        B2[Phê duyệt thanh toán]
        B3[Ghi nhận doanh thu]
    end
    S2 -->|Sự kiện OrderPlaced| F1
    F2 -->|Sự kiện StockReserved| S2
    S2 -->|Hợp đồng BillableOrder| B1
    B2 -->|Sự kiện PaymentAccepted| S2
    F3 -->|Sự kiện ShipmentDelivered| B3

Trong cấu trúc trên, đơn bán hàng và lệnh xuất kho có liên quan nhưng không phải cùng một đối tượng. Bán hàng quản lý giá, cam kết với khách hàng và trạng thái đơn, còn thực hiện đơn quản lý tồn kho vật lý và khả năng giao hàng. Nếu ngữ cảnh bán hàng trực tiếp sửa đối tượng tồn kho nội bộ của ngữ cảnh thực hiện đơn, thay đổi của hai đội sẽ bị kết dính, nên chỉ truyền những sự kiện cần thiết qua sự kiện tiếp nhận đơn và hợp đồng yêu cầu xuất kho.

3.3 Context map và quan hệ tích hợp

Context map trực quan hóa hướng phụ thuộc và loại quan hệ giữa các Bounded Context. Shared Kernel (nhân dùng chung) là một phần mô hình được nhiều đội cùng duy trì, đòi hỏi thỏa thuận thay đổi và kiểm thử chung. Shared Kernel trông giống tái sử dụng nhưng chi phí điều phối thay đổi lan sang mọi đội, nên an toàn hơn khi giới hạn ở các giá trị nhỏ và ổn định.

Trong quan hệ khách hàng - nhà cung cấp (Customer-Supplier), upstream cung cấp hợp đồng và downstream tiêu thụ. Cần quyết định downstream phải tuân theo nguyên mô hình của upstream hay đặt một lớp chuyển đổi để bảo vệ mô hình nội bộ. Nếu nhà cung cấp thay đổi thường xuyên hoặc độ tin cậy thấp, dùng lớp chống hư hại (ACL, Anti-Corruption Layer) để chuyển mô hình bên ngoài sang ngôn ngữ nội bộ.

Open Host Service cung cấp hợp đồng công khai được chuẩn hóa để nhiều bên tiêu thụ có thể sử dụng. Published Language (ngôn ngữ công bố) là cách biểu diễn được nhiều ngữ cảnh thống nhất, như lược đồ sự kiện hoặc tài liệu API. Quan hệ này tiện lợi, nhưng nếu không có quản lý phiên bản hợp đồng và kiểm thử tương thích ngược thì sự kết dính giữa các ngữ cảnh sẽ lại tăng lên.

Quan hệ	Ý nghĩa	Thời điểm áp dụng	Điểm kiểm soát
Shared Kernel	Đồng sở hữu một phần mô hình	Tính chung miền mạnh và hợp tác chặt chẽ	Phê duyệt thay đổi, kiểm thử chung
Customer-Supplier	Upstream cung cấp hợp đồng	Khi hướng cung cấp trong luồng nghiệp vụ rõ ràng	Phiên bản hợp đồng, phân tích tác động
Conformist	Downstream chấp nhận mô hình upstream	Khi thay đổi mô hình bên ngoài ít lợi ích	Giới hạn phạm vi ô nhiễm nội bộ
Anti-Corruption Layer	Chuyển mô hình ngoài sang mô hình trong	Khi liên kết hệ thống cũ (legacy), gói phần mềm	Quy tắc chuyển đổi, xử lý lỗi
Hợp tác qua sự kiện	Chia sẻ bất đồng bộ sự kiện nghiệp vụ	Khi cần giảm kết dính theo thời gian	Trùng lặp, thứ tự, xử lý lại

4. Thiết kế chiến thuật: thành phần mô hình và luồng thực thi

4.1 Entity và Value Object

Entity là đối tượng duy trì tính đồng nhất nhờ định danh dù thuộc tính thay đổi. Đơn hàng có cùng mã đơn vẫn là cùng một đơn dù địa chỉ giao hàng thay đổi, còn bản thân địa chỉ có thể hoàn chỉnh ý nghĩa bằng tổ hợp các giá trị. Định danh của Entity có thể là giá trị tự tăng của cơ sở dữ liệu, nhưng tách định danh có ý nghĩa nghiệp vụ khỏi định danh kỹ thuật sẽ có lợi cho hợp đồng bên ngoài.

Value Object (đối tượng giá trị) xác định tính đồng nhất bằng giá trị thuộc tính và điều kiện bất biến. Số tiền không chỉ là một con số mà có thể bao gồm đơn vị tiền tệ, độ chính xác và quy tắc làm tròn; địa chỉ email có thể bao gồm quy tắc định dạng và chuẩn hóa. Làm Value Object bất biến giúp giảm tác dụng phụ do chia sẻ, và có thể chặn trạng thái sai ngay tại constructor hoặc factory.

"Primitive obsession" — truyền kiểu nguyên thủy đi khắp nơi — gây nhầm lẫn đơn vị và bỏ sót kiểm tra hợp lệ. Ví dụ, chỉ với giá trị 1000 thì không thể biết đó là số tiền won hay điểm thưởng, có bao gồm VAT hay không. Các kiểu có ý nghĩa như Money, CustomerId, DeliveryAddress giúp trình biên dịch và kiểm thử bảo đảm quy tắc nghiệp vụ.

4.2 Aggregate và bất biến

Aggregate là nhóm đối tượng được xem như một ranh giới nhất quán, và bên ngoài chỉ được thay đổi phần bên trong thông qua aggregate root. Nếu đơn hàng là root, thay vì sửa trực tiếp dòng đơn hàng, hành vi như addLineItem của đơn hàng sẽ bảo đảm quy tắc về số lượng, giá và trạng thái. Aggregate không phải là thiết kế gộp nhiều đối tượng, mà là thiết kế tìm ra đơn vị nhỏ nhất bắt buộc phải nhất quán cùng nhau.

Nếu Aggregate quá lớn, dữ liệu phải khóa và giao dịch mỗi lần tăng lên, làm giảm tính đồng thời. Ngược lại, nếu quá nhỏ, để xử lý một lệnh nghiệp vụ phải sửa đồng thời nhiều Aggregate, dẫn đến cần giao dịch phân tán hoặc xử lý bù trừ. Vì vậy, ranh giới được quyết định bởi bất biến, tần suất thay đổi và mẫu hình đồng thời hơn là quan hệ bao hàm tự nhiên giữa các đối tượng.

Tham chiếu giữa các Aggregate thường được biểu diễn bằng định danh thay vì giữ trực tiếp đối tượng. Nếu đơn hàng giữ toàn bộ đối tượng khách hàng, thay đổi mô hình khách hàng sẽ lan sang mô hình đơn hàng, nên chỉ lưu CustomerId và lấy thông tin khách hàng cần thiết qua truy vấn riêng hoặc sự kiện. Cách này giảm kết dính nhưng phải thiết kế kèm vấn đề nhất quán khi truy vấn và độ mới của cache.

4.3 Domain Service và Application Service

Domain Service biểu diễn quy tắc miền khó gán một cách tự nhiên cho một Entity duy nhất. Những quy tắc cần sự hợp tác của nhiều Aggregate như chuyển tiền giữa hai tài khoản, hoặc không phải trách nhiệm bản chất của một đối tượng cụ thể như tra cứu tỷ giá, là ứng viên cho Domain Service. Tuy nhiên, nếu đẩy mọi phép tính sang service sẽ tạo ra mô hình miền "thiếu máu" (anemic), nên trước tiên hãy gán trách nhiệm cho Entity và Value Object rồi chỉ đặt phần quy tắc còn lại vào service.

Application Service điều phối use case của người dùng. Nó nhận lệnh, kiểm tra quyền, lấy Aggregate từ Repository, gọi hành vi miền, đồng thời điều phối giao dịch và phát hành sự kiện. Nếu viết trực tiếp quy tắc nghiệp vụ trong Application Service, quy tắc sẽ bị nhân bản ở nhiều điểm vào, nên service cần được giữ gần với vai trò điều phối luồng.

Phân biệt Domain Service và Application Service không phải là vấn đề tên tầng. Phép tính có ý nghĩa nghiệp vụ như "khách hàng này có phải VIP không" có thể thuộc về miền, còn luồng kỹ thuật như "nhận yêu cầu HTTP và chuyển sang JSON" thuộc tầng ứng dụng/giao diện. Phải quyết định vị trí dựa trên lý do trách nhiệm thay đổi thì kiểm thử và bảo trì mới dễ dàng.

4.4 Domain Event và Repository

Domain Event biểu thị rằng một sự kiện có ý nghĩa đã xảy ra trong miền. Các sự kiện như OrderPlaced, PaymentAccepted, ShipmentDelivered được biểu diễn ở thì quá khứ, để bên phát hành không cần biết hiện thực bên trong của bên tiêu thụ. Sự kiện khác với lệnh, nên truyền sự kiện như "đơn hàng đã được tiếp nhận" thay vì "hãy trừ tồn kho" sẽ giảm kết dính giữa các ngữ cảnh.

Repository trừu tượng hóa việc lưu và khôi phục Aggregate như một tập hợp (collection) theo góc nhìn miền. Tầng miền dùng các hợp đồng có ý nghĩa như findById, save thay vì chi tiết SQL hay ORM, và tầng hạ tầng sẽ hiện thực chúng. Tuy nhiên, nếu xử lý mọi truy vấn bằng mô hình đối tượng qua Repository, hiệu năng các truy vấn báo cáo phức tạp có thể giảm, nên cũng cần cân nhắc tách riêng mô hình truy vấn chỉ đọc.

Nếu tách rời việc phát hành sự kiện và lưu trữ, có thể xảy ra tình huống lưu thành công nhưng sự kiện bị mất. Để giảm thiểu, có thể áp dụng mẫu Outbox: ghi Domain Event vào outbox trong cùng giao dịch cục bộ, và một bộ chuyển phát riêng sẽ thử lại. Khi đó bên tiêu thụ có thể nhận sự kiện trùng, nên phải thiết kế xử lý trùng lặp dựa trên ID sự kiện và khóa idempotency (tính lũy đẳng).

4.5 Luồng chuẩn xử lý lệnh

Ứng dụng DDD thường được hiện thực theo luồng: adapter đầu vào, Application Service, mô hình miền, hạ tầng lưu trữ/thông điệp. Nếu không phơi bày DTO đầu vào trực tiếp thành Entity mà chuyển thành đối tượng lệnh, có thể tách tốc độ thay đổi của hợp đồng API bên ngoài với mô hình bên trong.

sequenceDiagram
    participant C as Client
    participant A as Application Service
    participant R as Repository
    participant AR as Aggregate Root
    participant O as Outbox
    participant P as Event Publisher
    C->>A: PlaceOrder Command
    A->>R: load(CustomerId, ProductIds)
    R-->>A: Aggregate/Value Objects
    A->>AR: place(order lines)
    AR-->>A: OrderPlaced domain event
    A->>R: save(aggregate)
    A->>O: append(event, idempotency key)
    A-->>C: OrderId and status
    P->>O: read pending event
    P-->>C: downstream effects eventually completed

Trong luồng này, Aggregate kiểm tra bất biến về giá và trạng thái, còn Application Service điều phối ranh giới giao dịch. Nếu việc ghi outbox không nằm trong cùng giao dịch, đơn hàng có thể đã được lưu nhưng sự kiện đặt giữ tồn kho lại biến mất. Ngược lại, nếu hiển thị ngay kết quả xử lý sự kiện của bên tiêu thụ cho người dùng như trạng thái đã xác nhận, có thể gây hiểu lầm về độ trễ bất đồng bộ, nên cần phân biệt trạng thái Đã tiếp nhận và Đã xử lý xong.

5. So sánh DDD với các cách tiếp cận tương tự

5.1 DDD và thiết kế hướng dữ liệu

Thiết kế hướng dữ liệu chú trọng chuẩn hóa, toàn vẹn, hiệu năng truy vấn và tích hợp dữ liệu. DDD chú trọng dữ liệu biểu diễn hành vi và quy tắc nghiệp vụ nào, và trách nhiệm thay đổi nằm ở đâu. Hai cách này không đối lập; trong hệ thống phức tạp cần có ánh xạ giữa mô hình miền và mô hình lưu trữ quan hệ.

Nếu gộp đơn hàng, khách hàng, sản phẩm thành một mô hình chung theo hướng bảng, việc lập báo cáo có vẻ tiện lợi, nhưng các quy tắc khác nhau của bán hàng, thực hiện đơn, quyết toán có thể bị đan xen trong một lược đồ. DDD cho phép mỗi ngữ cảnh có mô hình riêng cần thiết, còn truy vấn tích hợp được cung cấp bằng mô hình đọc riêng hoặc sản phẩm dữ liệu (data product). Đổi lại, phải chấp nhận dữ liệu trùng lặp và chi phí đồng bộ, nên cần cân bằng giữa yêu cầu nhất quán và sự tiện lợi khi truy vấn.

5.2 DDD và microservice

Microservice là phong cách kiến trúc thu nhỏ đơn vị triển khai, mở rộng và cô lập sự cố, còn DDD là cách tiếp cận thiết kế để khám phá mô hình và ranh giới nghiệp vụ. Bounded Context của DDD có thể là ứng viên microservice, nhưng cũng có thể chia một ngữ cảnh thành nhiều dịch vụ, hoặc ban đầu hiện thực nhiều ngữ cảnh trong một modular monolith. Nếu dùng DDD làm lý do chia tách dịch vụ mà không có căn cứ, chỉ có lời gọi mạng và độ phức tạp vận hành tăng lên.

Modular monolith (khối nguyên khối mô-đun) là cách giữ một đơn vị triển khai duy nhất trong khi vẫn tuân thủ mô-đun và hợp đồng giữa các ngữ cảnh. Nó phù hợp với chiến lược tiệm tiến: kiểm chứng ranh giới miền, bảo đảm năng lực vận hành của đội, rồi chỉ tách thành dịch vụ những ngữ cảnh có xung đột thay đổi hoặc nhu cầu mở rộng rõ ràng. Ngược lại, trong tổ chức quy mô lớn cần triển khai độc lập và cô lập sự cố mạnh ngay từ đầu, dịch vụ theo từng ngữ cảnh có thể hợp lý.

Tiêu chí so sánh	DDD	Thiết kế hướng dữ liệu	Microservice
Mối quan tâm chính	Ý nghĩa nghiệp vụ và ranh giới thay đổi	Toàn vẹn và khai thác dữ liệu	Triển khai, mở rộng, cô lập sự cố
Tiêu chí ranh giới	Ngôn ngữ, bất biến, lý do thay đổi	Lược đồ, quan hệ thực thể	Đơn vị vận hành dịch vụ
Tính nhất quán	Nhất quán mạnh theo từng Aggregate, eventual consistency giữa các ngữ cảnh	Dễ đạt nhất quán mạnh bằng giao dịch tập trung	Thường xuyên xử lý bất đồng bộ, bù trừ giữa các dịch vụ
Ưu điểm	Tính gắn kết của quy tắc nghiệp vụ phức tạp	Truy vấn tích hợp và quản lý tính đúng đắn	Triển khai và mở rộng độc lập
Rủi ro	Chi phí mô hình hóa, hợp tác	Quy tắc phân tán và lược đồ khổng lồ	Gánh nặng vận hành hệ phân tán
Điều kiện phù hợp	Nghiệp vụ cốt lõi phức tạp và biến động	CRUD đơn giản, phân tích tích hợp	Yêu cầu đội, triển khai, mở rộng độc lập

6. Tình huống áp dụng: nền tảng đặt hàng trực tuyến và quyết toán

Giả sử trên một nền tảng thương mại điện tử, bán hàng, tồn kho, giao hàng và thanh toán dùng chung một bảng đơn hàng. Nếu thay đổi coupon giảm giá ảnh hưởng đến xử lý tồn kho, và thay đổi trạng thái giao hàng ảnh hưởng đến lô ghi nhận doanh thu, thì ngay cả thay đổi chính sách nhỏ cũng dẫn đến triển khai toàn bộ. Trước hết, chia đơn bán hàng, thực hiện tồn kho, thanh toán và quyết toán thành các ngữ cảnh, rồi định nghĩa ngôn ngữ chung của từng ngữ cảnh.

Ngữ cảnh bán hàng chịu trách nhiệm tạo đơn, hủy đơn, áp dụng giảm giá và cam kết với khách hàng. Aggregate đơn hàng quản lý chung dòng đơn hàng và kết quả giảm giá, nhưng không trực tiếp thay đổi đối tượng tồn kho thực tế. Khi đơn hàng được tiếp nhận, nó phát hành sự kiện OrderPlaced và ngữ cảnh thực hiện đơn sẽ thử đặt giữ theo chính sách tồn kho của riêng mình.

Ngữ cảnh tồn kho chịu trách nhiệm số lượng khả dụng theo từng kho và thời hạn đặt giữ. Số lượng tồn kho mà bán hàng hiển thị và tồn kho vật lý mà thực hiện đơn xác nhận có thể khác nhau về thời điểm và mục đích, nên không xem hai giá trị này là một trường chung. Đặt giữ thành công được thông báo bằng StockReserved, thất bại bằng StockReservationFailed, và ngữ cảnh bán hàng chuyển đơn sang trạng thái chờ, hủy hoặc thay thế.

Ngữ cảnh thanh toán chịu trách nhiệm phê duyệt, hủy, hoàn tiền và chính sách bảo mật phương tiện thanh toán. Ngay cả khi yêu cầu người dùng bị timeout do phản hồi chậm từ công ty thẻ, khóa yêu cầu thanh toán được dùng làm khóa idempotency để việc thử lại không gây thanh toán trùng. Sự kiện hoàn tất thanh toán là căn cứ cập nhật trạng thái đơn và bản ghi quyết toán, nhưng hợp đồng được tách để ngữ cảnh thanh toán không trực tiếp thao tác trạng thái nội bộ của bán hàng.

Ngữ cảnh quyết toán xác nhận doanh thu và khoản phải thu theo tiêu chuẩn kế toán, thuế và phí chứ không theo giá đơn hàng. Nếu dùng nguyên kết quả tính giảm giá của bán hàng làm sổ cái kế toán thì khó truy vết thay đổi quy định và chênh lệch làm tròn, nên quyết toán sở hữu riêng chứng từ và quy tắc tính toán cần thiết. Cấu trúc này khiến dữ liệu bị trùng một phần, nhưng cho phép thay đổi độc lập quy tắc của từng ngữ cảnh và lưu lại vết kiểm toán.

Cụ thể, với nền tảng xử lý 1 triệu đơn mỗi tháng, cấu trúc dùng sự kiện tiếp nhận đơn và mô hình đọc chuyên cho quyết toán có thể có lợi cho khả năng mở rộng hơn là cấu trúc mọi ngữ cảnh đều join bảng đơn hàng. Tuy nhiên, nếu sự kiện trễ 30 giây, trạng thái trên trung tâm chăm sóc khách hàng và dashboard vận hành có thể hiển thị chậm, nên phải thiết kế kèm SLA và truy vấn hiệu chỉnh. DDD không phải là khẩu hiệu chọn phân tán mà là phương pháp làm rõ mức độ nhất quán và chi phí thất bại nghiệp vụ.

7. Chuyên sâu: áp dụng tiệm tiến và thiết kế vận hành

7.1 Áp dụng trên hệ thống cũ (legacy)

Áp dụng DDD một lần vào hệ thống cũ có thể làm tổn hại tính ổn định của chức năng hiện có. Trước hết, chọn luồng nghiệp vụ thay đổi thường xuyên và chi phí sự cố lớn, sau đó xác nhận thuật ngữ và ranh giới bằng Event Storming hoặc workshop. Nếu không viết lại ngay hệ thống bên ngoài mà bảo vệ từ vùng ngoại vi bằng ACL và facade, có thể kiểm chứng mô hình mới một cách tiệm tiến.

Với mẫu Strangler, có thể thêm ngữ cảnh mới phía trước chức năng hiện có và dần chuyển trách nhiệm theo lưu lượng hoặc loại nghiệp vụ. Ở giai đoạn đầu hiện thực, có thể tham chiếu cơ sở dữ liệu cũ ở chế độ chỉ đọc, nhưng khi mô hình mới có quyền sở hữu thì phải tách đường ghi và quan sát độ trễ đồng bộ. Tiêu chí hoàn tất chuyển đổi không được định nghĩa bằng lượng mã mà bằng quyền sở hữu quy tắc nghiệp vụ, tính đúng đắn dữ liệu và khả năng khôi phục sự cố.

7.2 Workshop mô hình hóa và chỉ số chất lượng

Khi chuyên gia miền, nhà phát triển, người lập kế hoạch và người vận hành cùng liệt kê các sự kiện ở thì quá khứ và các lệnh, luồng nghiệp vụ và ngoại lệ sẽ nhanh chóng lộ ra. Nếu chỉ ghi luồng bình thường, mô hình sẽ đơn giản hóa thực tế quá mức, nên phải bao gồm hủy, trả hàng, xử lý lại, ngoại lệ pháp lý và từ chối quyền. Kết quả workshop được tổng hợp thành bảng thuật ngữ, context map, danh sách bất biến, hợp đồng sự kiện và các câu hỏi chưa quyết định.

Chất lượng DDD không thể đánh giá bằng số lớp hay số dịch vụ. Các chỉ số cốt lõi có thể bao gồm phạm vi ảnh hưởng khi thay đổi, tỷ lệ xung đột Aggregate, số lời gọi đồng bộ giữa các ngữ cảnh, tỷ lệ xử lý lại sự kiện thành công, độ bao phủ kiểm thử quy tắc và số trường hợp không thống nhất thuật ngữ nghiệp vụ. Ví dụ, quan sát xem thay đổi quy tắc hủy đơn có kết thúc chỉ bằng kiểm thử và triển khai ngữ cảnh bán hàng, hay cần điều chỉnh thủ công cả thanh toán, giao hàng và quyết toán.

7.3 Kiểm soát vận hành tích hợp hướng sự kiện

Cấu trúc hướng sự kiện giảm kết dính nhưng tạo ra các dạng thất bại mới: trễ chuyển phát, trùng lặp, đảo thứ tự và sự cố bên tiêu thụ. Lược đồ sự kiện chứa thời điểm phát sinh, định danh, phiên bản và ngữ cảnh nguồn, còn bên tiêu thụ phải có cách xử lý an toàn khi thứ tự bị đảo và chính sách xử lý lại. Nếu không quan sát DLQ, số lần thử lại, độ trễ xử lý và lag theo từng bên tiêu thụ, eventual consistency sẽ trông như sự không nhất quán dữ liệu đơn thuần.

Kiểm thử hợp đồng (contract test) tự động kiểm chứng trường, ý nghĩa, tính bắt buộc và tương thích ngược giữa bên phát hành và bên tiêu thụ. Ngay cả khi dùng schema registry hoặc chính sách phiên bản, chỉ việc tên trường giống nhau không bảo đảm ý nghĩa nghiệp vụ. Ghi ý nghĩa của sự kiện và việc có chứa thông tin cá nhân hay không vào danh mục (catalog), đồng thời gắn thời hạn lưu giữ và quyền truy cập với quản trị dữ liệu.

8. Các điểm cần cân nhắc và hàm ý

8.1 Độ phức tạp và phạm vi đầu tư

DDD cần được ưu tiên áp dụng cho nghiệp vụ cốt lõi có độ phức tạp miền cao. Nếu bọc mọi màn hình tra cứu/quản lý đơn giản bằng Aggregate và sự kiện, chi phí sản phẩm thiết kế và kiểm thử có thể lớn hơn giá trị nghiệp vụ. Cần phân cấp độ sâu mô hình hóa và mức độ tách biệt theo tần suất thay đổi quy tắc nghiệp vụ và chi phí thất bại.

8.2 Ranh giới và trách nhiệm tổ chức

Bounded Context phải phản ánh không chỉ mô-đun kỹ thuật mà cả trách nhiệm và quyền quyết định của đội. Nếu đội không có quyền thay đổi hợp đồng mà chỉ tách dịch vụ, các cuộc họp điều phối và triển khai khẩn cấp trong vận hành sẽ tăng. Cần làm rõ người chịu trách nhiệm sản phẩm, chủ sở hữu dữ liệu, on-call, SLO và người phê duyệt thay đổi theo từng ngữ cảnh để định luật Conway không biểu hiện thành sự kết dính hỗn loạn.

8.3 Tính nhất quán và trải nghiệm người dùng

Khi chấp nhận eventual consistency giữa các ngữ cảnh, phải phân biệt trạng thái người dùng nhìn thấy và trạng thái đã xác nhận. Nếu ngay sau khi tiếp nhận đơn mà khả năng giao hàng chưa được xác nhận, UI và API phải thể hiện Đang xử lý, và khi thất bại phải cung cấp lộ trình thử lại, thay thế hoặc hoàn tiền. Mục tiêu độ trễ nhất quán cần được lượng hóa theo từng nghiệp vụ, và khi độ trễ vượt mục tiêu thì tác vụ hiệu chỉnh và cảnh báo phải được kích hoạt.

8.4 Dữ liệu, bảo mật, kiểm toán

Khi các ngữ cảnh sở hữu dữ liệu riêng rẽ, việc sao chép thông tin cá nhân và xử lý yêu cầu xóa có thể trở nên phức tạp. Không đưa số định danh cá nhân hay dữ liệu thanh toán gốc vào sự kiện mà chỉ truyền định danh và sự kiện nghiệp vụ tối thiểu, và khi cần thì áp dụng token hóa, che giấu (masking) và kiểm soát truy cập. Nghĩa vụ lưu giữ và hủy theo pháp luật có thể xung đột nhau, nên phải thiết kế đồng thời chính sách lưu giữ cho dữ liệu gốc, mô hình đọc dẫn xuất, log và bản sao lưu.

8.5 Hiệu năng và khôi phục sự cố

Giao dịch theo đơn vị Aggregate có lợi cho bảo vệ bất biến, nhưng nếu lưu từng cái một trong xử lý lô khối lượng lớn thì thông lượng có thể giảm. Tách đường lệnh cốt lõi khỏi đường phân tích/tổng hợp, sử dụng mô hình chỉ đọc, xử lý lô và cache, nhưng không để cache trở thành sự thật cuối cùng của nghiệp vụ. Cần định kỳ kiểm chứng các thủ tục xử lý lại sự kiện, chống trùng lặp, bù trừ thất bại một phần và tái dựng dữ liệu.

8.6 Chiến lược bài làm từ góc nhìn Kỹ sư chuyên nghiệp

Bài làm hiệu quả nên trình bày trước độ phức tạp miền và sự cần thiết của DDD, rồi giải thích ranh giới miền con và Bounded Context bằng sơ đồ khái niệm. Tiếp theo, liên kết ngôn ngữ chung, Entity, Value Object, Aggregate và Domain Event dưới góc độ bất biến và giao dịch. Về quan hệ với microservice, cần sửa hiểu lầm "DDD chính là microservice" và so sánh ưu nhược điểm của modular monolith với việc tách tiệm tiến.

Phần kết luận phải trình bày các đánh đổi về chi phí, hiệu năng, tính nhất quán, bảo mật và trách nhiệm tổ chức. Không chỉ nhắc đến hợp tác với chuyên gia miền và bảng thuật ngữ, mà cần liên kết kiểm thử hợp đồng, Outbox, idempotency, khả năng quan sát và diễn tập khôi phục thành phương án vận hành. Kỹ sư chuyên nghiệp nên là người ra quyết định kiến trúc, chọn mức độ phù hợp với ranh giới vấn đề và lý do thay đổi, thay vì khuyến nghị áp dụng một mẫu cụ thể.

Tài liệu tham khảo

Martin Fowler, Domain-Driven Design: https://martinfowler.com/bliki/DomainDrivenDesign.html
Martin Fowler, Bounded Context: https://martinfowler.com/bliki/BoundedContext.html
Martin Fowler, Repository: https://martinfowler.com/eaaCatalog/repository.html
Microsoft Azure Architecture Center, Domain analysis: https://learn.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis
Microsoft Azure Architecture Center, Tactical DDD: https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd

Tóm tắt một câu: DDD là cách thiết kế làm tường minh ngôn ngữ và quy tắc nghiệp vụ bằng Bounded Context, Aggregate và sự kiện để giữ vững ranh giới thay đổi của hệ thống phức tạp, và cần được áp dụng tiệm tiến tương ứng với độ phức tạp miền cùng năng lực vận hành của tổ chức.