Software Architecture

Tư duy hướng Domain (Domain-Driven Design): Bản chất của việc chia tách hệ thống

7/19/2026 · 12p đọc

title: "Tư duy hướng Domain (Domain-Driven Design): Bản chất của việc chia tách hệ thống"
series: "Software Architecture Masterclass"
part: "Phần 1 — Nguyên lý & Triết lý Kiến trúc"
order: 9
audience: "Solutions Architect & Technical Lead"
reading_time: "13 phút"
tags: ["domain-driven-design", "ubiquitous-language", "bounded-context", "system-design", "trade-off"]

Tư duy hướng Domain (Domain-Driven Design): Bản chất của việc chia tách hệ thống

Một hệ thống CRM sau ba năm phát triển có cấu trúc thư mục như sau: controllers/ chứa 40 file controller cho mọi domain từ khách hàng, hợp đồng, đến kế toán; services/ chứa 60 file service gọi chéo nhau không theo quy tắc nào; repositories/ chứa các lớp truy cập DB dùng chung cho mọi bảng. Khi Product yêu cầu thay đổi logic tính hoa hồng bán hàng — một thay đổi nghiệp vụ tưởng như đơn giản — kỹ sư phải sửa SalesController, CommissionService, AccountingService, NotificationService, và hai migration liên quan đến bảng orders. Bốn kỹ sư, năm ngày, ba lần regression không lường trước ở module kế toán.

Vấn đề không nằm ở số lượng code. Vấn đề nằm ở trục tổ chức: hệ thống được chia theo loại kỹ thuật (controller, service, repository) thay vì theo năng lực nghiệp vụ (bán hàng, hoa hồng, kế toán, thông báo). Một thay đổi nghiệp vụ — vốn dĩ chỉ nên chạm vào một khu vực — bị rải mỏng ra khắp hệ thống, vì ranh giới code không khớp với ranh giới nghiệp vụ.

Domain-Driven Design (DDD — thiết kế hướng miền nghiệp vụ) ra đời chính xác để giải bài toán này: nó là phương pháp luận buộc kiến trúc sư đặt câu hỏi "hệ thống này phục vụ nghiệp vụ gì?" trước khi hỏi "hệ thống này dùng công nghệ gì?". Bài này sẽ đi vào bản chất của tư duy hướng domain — không phải như một bộ pattern để copy, mà như một lăng kính để nhìn lại toàn bộ cách bạn chia tách hệ thống.

The Problem

Bài toán kiến trúc cụ thể: một đội kỹ thuật tổ chức codebase theo tầng kỹ thuật (technical layering) — tất cả controller nằm chung một thư mục, tất cả logic truy cập database dùng chung một tập repository, tất cả business logic đổ vào một tầng "service" khổng lồ không phân biệt domain. Cách tổ chức này quen thuộc vì nó phản chiếu cách các framework MVC dạy người mới bắt đầu: Model — View — Controller, mỗi loại một thư mục.

Vấn đề xuất hiện khi hệ thống lớn lên và nghiệp vụ thay đổi liên tục — điều tất yếu ở mọi công ty sống được quá hai năm:

  1. Một thay đổi nghiệp vụ chạm vào nhiều service không liên quan trực tiếp. Sửa quy tắc "khách hàng VIP được giảm giá 10%" phải đụng vào CustomerService, PricingService, OrderService, InvoiceService — vì logic tính giá bị rải rác theo tầng kỹ thuật thay vì gói gọn trong một domain "Pricing".
  2. Không ai sở hữu trọn vẹn một năng lực nghiệp vụ. Khi tầng service là một khối chung, mọi kỹ sư đều có thể sửa mọi thứ — nghĩa là không ai thực sự chịu trách nhiệm sâu về logic nghiệp vụ nào cả. Kiến thức domain phân mảnh trong đầu nhiều người, không mã hoá được vào cấu trúc code.
  3. Ngôn ngữ giữa dev và nghiệp vụ lệch nhau. Chuyên gia nghiệp vụ (business expert / domain expert) nói "hợp đồng được kích hoạt (activate)", dev code thành contract.status = 1. Khi có bug, hai bên nói chuyện bằng hai ngôn ngữ khác nhau, mất thời gian dịch qua dịch lại, và bản dịch luôn rò rỉ ý nghĩa.
  4. Thay đổi ở một service tầng kỹ thuật gây hiệu ứng domino không kiểm soát được — vì ranh giới file không phản ánh ranh giới nghiệp vụ, một sửa đổi tưởng nhỏ (đổi field trong bảng orders) có thể phá vỡ logic ở một domain hoàn toàn khác đang vô tình phụ thuộc vào field đó.

Gốc rễ: tổ chức theo tầng kỹ thuật tối ưu cho sự tiện lợi khi viết code lần đầu (biết ngay controller nằm ở đâu), nhưng lại tối ưu ngược cho chi phí thay đổi nghiệp vụ về sau — trong khi thay đổi nghiệp vụ mới là hoạt động chiếm phần lớn vòng đời của một hệ thống sống lâu.

The Theory

Domain-Driven Design, được Eric Evans hệ thống hóa, xuất phát từ một tiền đề đơn giản nhưng triệt để: độ phức tạp thật sự của phần mềm doanh nghiệp nằm ở domain (miền nghiệp vụ), không nằm ở công nghệ — và do đó, cấu trúc phần mềm nên được tổ chức xoay quanh domain, không xoay quanh loại kỹ thuật.

Ba trụ cột của tư duy hướng domain:

1. Ubiquitous Language (ngôn ngữ chung xuyên suốt). Đây là trụ cột nền tảng nhất, và thường bị bỏ qua đầu tiên. Ubiquitous Language là bộ thuật ngữ được dev và chuyên gia nghiệp vụ cùng thống nhất, dùng nhất quán ở mọi nơi: trong cuộc họp, trong tài liệu, và trong chính tên class/method/biến trong code. Nếu chuyên gia nghiệp vụ gọi hành động là "kích hoạt hợp đồng" (activate contract), thì code phải có method tên activateContract(), không phải setStatus(1). Khi ngôn ngữ khớp nhau, khoảng cách dịch thuật giữa yêu cầu nghiệp vụ và implementation gần như biến mất — bug ít hơn vì không còn tầng "hiểu nhầm khi dịch" ở giữa.

2. Domain Model là trung tâm, không phải database schema. DDD đảo ngược thứ tự tư duy quen thuộc: thay vì thiết kế bảng DB trước rồi sinh ra entity từ đó (data-driven design), DDD yêu cầu mô hình hóa các khái niệm nghiệp vụ trước (Customer, Contract, Commission, Invoice — với hành vi và quy tắc của chúng), rồi mới ánh xạ (map) xuống schema lưu trữ. Một Contract trong domain model không phải là một hàng dữ liệu thụ động — nó có hành vi (activate(), terminate(), renew()) và tự bảo vệ các bất biến (invariant) của chính nó, ví dụ không cho phép activate() một hợp đồng đã terminated.

3. Bounded Context (ranh giới ngữ nghĩa) — sẽ được đào sâu ở bài kế tiếp. DDD thừa nhận một sự thật khó chịu: cùng một từ có thể mang nghĩa khác nhau ở các phần khác nhau của tổ chức. "Customer" trong domain Sales là người có khả năng ra quyết định mua; "Customer" trong domain Support là người đang cần được hỗ trợ; "Customer" trong domain Billing là một pháp nhân có mã số thuế. DDD không cố ép một model "Customer" chung cho tất cả — nó vẽ ranh giới (bounded context) quanh mỗi cách hiểu, và chỉ đồng nhất ngôn ngữ trong nội bộ ranh giới đó.

Quy trình áp dụng tư duy domain vào việc chia tách hệ thống gồm bốn bước:

  1. Event Storming hoặc phỏng vấn domain expert — ngồi cùng người làm nghiệp vụ thật (sales, kế toán, vận hành), không chỉ đọc spec, để tìm ra các "domain event" (sự kiện nghiệp vụ) thật sự xảy ra: "Hợp đồng được ký", "Hoa hồng được tính", "Đơn hàng bị huỷ".
  2. Nhóm các domain event thành domain/subdomain — các sự kiện nào luôn đi cùng nhau, dùng chung một tập quy tắc nghiệp vụ, sẽ thuộc cùng một domain (ví dụ: toàn bộ vòng đời tính và chi trả hoa hồng thuộc domain "Commission").
  3. Xây dựng Ubiquitous Language cho từng domain — lập bảng thuật ngữ, thống nhất với domain expert, rồi bắt buộc dùng đúng thuật ngữ đó trong tên class/method.
  4. Ánh xạ domain xuống cấu trúc module — mỗi domain trở thành một module/package độc lập, chứa trọn vẹn logic, entity, và (nếu cần) cả tầng truy cập dữ liệu riêng cho domain đó — thay vì rải theo tầng kỹ thuật dùng chung.

Điểm mấu chốt: DDD không phải là "đặt tên thư mục theo tính năng thay vì theo tầng" — đó chỉ là hệ quả bề mặt. Bản chất là đầu tư nghiêm túc vào việc hiểu đúng nghiệp vụ trước khi viết một dòng code, và để cấu trúc phần mềm là tấm gương phản chiếu trung thực của sự hiểu biết đó.

The Trade-off

Đây là phần phải rất rõ ràng, vì DDD là một trong những khái niệm bị hiểu sai nhiều nhất trong ngành — người ta hay chỉ nói "được gì" mà giấu đi "mất gì".

Được gì:

  • Thay đổi nghiệp vụ được khoanh vùng. Khi domain "Commission" là một module gói gọn, thay đổi quy tắc tính hoa hồng chỉ chạm vào module đó — không lan ra OrderService, InvoiceService như ví dụ mở bài. Chi phí thay đổi tỷ lệ thuận với độ phức tạp nghiệp vụ thật, không tỷ lệ thuận với số lượng service vô tình phụ thuộc chéo.
  • Giảm chi phí giao tiếp giữa dev và nghiệp vụ về lâu dài. Khi ubiquitous language được thiết lập, một buổi họp giữa PM và dev không còn tốn 30 phút để "dịch" giữa thuật ngữ nghiệp vụ và tên biến trong code — cả hai bên nói cùng một từ, cùng một nghĩa.
  • Domain model mang theo tri thức nghiệp vụ một cách tường minh, không phụ thuộc vào trí nhớ cá nhân. Một kỹ sư mới join có thể đọc code domain Contract và hiểu được quy tắc nghiệp vụ (invariant) mà không cần hỏi lại người cũ — vì bất biến được code hóa ngay trong entity, không nằm rải rác trong đầu vài người.

Mất gì — và đây là phần thường bị giấu:

  • Chi phí hợp tác với domain expert là có thật và tốn kém, không phải một dòng trong kế hoạch. Event Storming nghiêm túc, phỏng vấn domain expert, xây dựng ubiquitous language không phải việc làm một lần — nó đòi hỏi nhiều buổi họp liên tục với người làm nghiệp vụ (sales lead, kế toán trưởng, vận hành), những người vốn đã bận và không rảnh để "dạy" domain cho dev. Nếu tổ chức của bạn không có domain expert sẵn sàng đầu tư thời gian này, DDD sẽ chỉ dừng lại ở việc đổi tên thư mục — mất công sức mà không thu được lợi ích cốt lõi.
  • Tốc độ ra tính năng ban đầu chậm hơn so với tổ chức theo tầng kỹ thuật. Viết một CRUD đơn giản theo tầng kỹ thuật (route → service → repository dùng chung) nhanh hơn nhiều so với việc dừng lại, mô hình hóa domain, định nghĩa bounded context, viết ubiquitous language — với một tính năng nhỏ hoặc một sản phẩm đang ở giai đoạn tìm kiếm thị trường (early-stage), khoản đầu tư này có thể không bao giờ hoàn vốn vì domain còn đang thay đổi liên tục, model hôm nay có thể sai hoàn toàn vào tháng sau.
  • Rủi ro over-engineering nếu áp dụng cho domain đơn giản. Không phải mọi phần của hệ thống đều đáng được đầu tư domain-modeling sâu. Một module "quản lý danh sách nhãn (tags)" CRUD thuần túy không có quy tắc nghiệp vụ phức tạp — áp DDD đầy đủ vào đó (entity với hành vi, ubiquitous language riêng, bounded context riêng) là lãng phí, làm code phức tạp hơn mức cần thiết mà không tăng thêm giá trị nào.
  • Đòi hỏi kỹ năng mô hình hóa mà không phải kỹ sư nào cũng có sẵn. Phân biệt đúng ranh giới domain, viết entity có hành vi thay vì entity chỉ chứa dữ liệu (anemic model), tránh rò rỉ khái niệm giữa các bounded context — đây là kỹ năng cần thời gian rèn luyện. Áp dụng nửa vời (chỉ đổi cấu trúc thư mục mà không đổi tư duy) tạo ra ảo giác "đã làm DDD" trong khi bản chất vẫn là code theo tầng kỹ thuật, chỉ khoác lớp vỏ khác.

Nói ngắn gọn: DDD đánh đổi tốc độ ban đầu và chi phí hợp tác để lấy khả năng chịu đựng thay đổi nghiệp vụ về lâu dài — một khoản đầu tư chỉ hoàn vốn khi domain đủ phức tạp và đủ sống lâu để khoản đầu tư đó phát huy tác dụng.

The Architecture Diagram

flowchart TB
    subgraph TECH["Mô hình phân tầng kỹ thuật (Technical Layering)"]
        direction TB
        TC["Controllers<br/>(chung cho mọi domain)"]
        TS["Services<br/>(chung, gọi chéo nhau)"]
        TR["Repositories<br/>(truy cập DB dùng chung)"]
        TC --> TS --> TR

        CH1["Thay đổi: quy tắc hoa hồng"] -.chạm.-> TC
        CH1 -.chạm.-> TS
        CH1 -.chạm.-> TR
    end

    subgraph DOMAIN["Mô hình hướng Domain (Domain-Driven Design)"]
        direction LR

        subgraph SALES["Domain: Sales"]
            SC["Order Entity<br/>+ hành vi + invariant"]
        end

        subgraph COMM["Domain: Commission"]
            CC["Commission Entity<br/>+ quy tắc tính hoa hồng"]
        end

        subgraph ACC["Domain: Accounting"]
            AC["Invoice Entity<br/>+ quy tắc kế toán"]
        end

        CH2["Thay đổi: quy tắc hoa hồng"] -->|chỉ chạm| COMM
        SALES -.domain event.-> COMM
        COMM -.domain event.-> ACC
    end

    style TC fill:#7f1d1d,color:#fff
    style TS fill:#7f1d1d,color:#fff
    style TR fill:#7f1d1d,color:#fff
    style CC fill:#14532d,color:#fff
    style COMM fill:#14532d,color:#fff

Implementation Guardrails

  1. Xây bảng thuật ngữ chung (ubiquitous language glossary) trước khi viết entity đầu tiên. Bảng này liệt kê mỗi thuật ngữ nghiệp vụ, định nghĩa được domain expert xác nhận, và tên class/method tương ứng trong code. Không có bảng này (hoặc bảng chỉ nằm trong đầu một người), coi như chưa bắt đầu DDD.
  2. Một thuật ngữ domain không được mang hai nghĩa khác nhau trong cùng một bounded context. Nếu "Customer" ở domain Sales và domain Support có hai định nghĩa khác nhau, đó là tín hiệu cần tách thành hai bounded context riêng (xem bài kế tiếp) — không được nhồi hai nghĩa vào chung một entity Customer rồi dùng field/flag để phân biệt, vì điều đó sẽ tạo ra một model vừa đúng cho cả hai vừa đúng cho không cái nào.
  3. Entity trong domain model phải mang hành vi, không chỉ là túi chứa dữ liệu (anemic domain model). Contract.activate() phải tự kiểm tra bất biến của nó (ví dụ: không cho activate hợp đồng đã terminated) — logic đó không được đặt rời ở tầng service bên ngoài rồi thao túng field trực tiếp (contract.status = 1), vì như vậy quy tắc nghiệp vụ sẽ bị rải rác và dễ bị vi phạm ở nơi khác.
  4. Chỉ đầu tư mô hình hóa domain sâu cho domain lõi (core domain) — domain hỗ trợ (supporting/generic subdomain) dùng CRUD đơn giản là đủ. Đừng áp cùng một mức độ nghiêm ngặt DDD cho module quản lý "nhãn (tags)" như cho module "tính hoa hồng bán hàng" — mức đầu tư phải tỷ lệ với độ phức tạp nghiệp vụ thật của domain đó.

Architect's Verdict

DDD không phải một quy tắc đặt tên thư mục, và cũng không phải một chiếc búa để đập vào mọi hệ thống. Nó là một khoản đầu tư hợp tác — với domain expert, với ngôn ngữ, với việc hiểu đúng nghiệp vụ trước khi code — chỉ đáng bỏ ra khi domain đủ phức tạp và đủ sống lâu để hoàn vốn. Với domain lõi mang lại lợi thế cạnh tranh của doanh nghiệp (ví dụ engine tính hoa hồng, engine định giá phức tạp), DDD gần như là bắt buộc. Với các domain CRUD đơn giản hỗ trợ xung quanh, áp DDD đầy đủ là lãng phí công sức — hãy dành sự nghiêm ngặt đó cho nơi nó thực sự tạo ra giá trị.

🔗 Bài viết liên quan

Bài trước: Đo lường kiến trúc · Bài tiếp theo: Bounded Contexts

Tư duy hướng Domain (Domain-Driven Design): Bản chất của việc chia tách hệ thống