Domain-Driven Design on Thanh HV's Blog

Chương 16: Anti-patterns & Khi nào KHÔNG nên dùng DDD

Fri, 10 Jul 2026 00:00:00 +0700

Vị trí chương này trong tài liệu: Đây là chương cuối cùng. Sau khi đã đi qua toàn bộ strategic design (chương 01–05), tactical patterns (06–11), kiến trúc và distributed systems (12–13), đưa vào production (14) và các case study (15a, 15b), chương này làm hai việc mà một tài liệu trung thực bắt buộc phải làm: liệt kê những cách người ta làm hỏng DDD trong thực tế — với code thật, dấu hiệu nhận biết thật — và nói thẳng khi nào đừng dùng DDD. Cuối chương là phần tổng kết toàn bộ tài liệu và lộ trình học tiếp.

Chương 15b — Case Study: SaaS, Blockchain, Booking System, Social Network

Thu, 09 Jul 2026 23:00:00 +0700

Vị trí trong bộ tài liệu: nửa sau của phần case study. Chương 15a đi qua bốn ngành “kinh điển”; chương này chọn bốn ngành ở các thái cực khác nhau của trục nhất quán: SaaS (ranh giới tenant là luật sống còn), Blockchain exchange (nguồn sự thật nằm một nửa ngoài hệ thống của bạn), Booking (tranh chấp tài nguyên theo thời gian — bài toán strong consistency thuần khiết nhất), và Social Network (read-heavy, eventual consistency là mặc định nhưng moderation phức tạp bất ngờ). Đọc bốn ngành cạnh nhau để thấy: cùng một bộ pattern, liều lượng và điểm đặt hoàn toàn khác nhau — đó chính là kỹ năng của kiến trúc sư.

Chương 15a — Case Study: E-commerce, FinTech, Banking, Logistics

Thu, 09 Jul 2026 22:00:00 +0700

Vị trí trong bộ tài liệu: Đây là chương đầu tiên trong cặp chương case study (15a/15b), đứng sau Chương 14 — DDD trong Production. Toàn bộ lý thuyết từ chương 01–14 — Subdomain, Bounded Context, Context Mapping, Aggregate, Domain Event, kiến trúc và distributed systems — sẽ được “thử lửa” qua 4 ngành có độ phức tạp domain rất khác nhau: E-commerce, FinTech (ví điện tử/payment), Banking (core banking + lending), Logistics (last-mile delivery). Mục tiêu không phải là đưa cho bạn thiết kế để copy, mà là cho bạn thấy cách lập luận: cùng một pattern, tại sao ngành này dùng còn ngành kia thì không.

Chương 14: DDD trong Production — Refactoring, Adoption, Tổ chức Team và Vận hành Dài hạn

Thu, 09 Jul 2026 21:00:00 +0700

Vị trí chương này trong tài liệu: Sau khi đã nắm toàn bộ tactical patterns (chương 06–11), kiến trúc (chương 12) và distributed systems (chương 13), chương này trả lời câu hỏi thực tế nhất: làm sao đưa DDD vào một hệ thống đang chạy, đang có khách hàng, đang có team, đang có deadline? Đây là chương dành cho những người phải sống với hệ quả của quyết định kiến trúc — không phải trên slide, mà trong production lúc 2 giờ sáng. Chương tiếp theo (15a) sẽ áp dụng toàn bộ những gì bàn ở đây vào các case study cụ thể.

Chương 13: DDD và Distributed Systems

Thu, 09 Jul 2026 20:00:00 +0700

Vị trí trong lộ trình: Chương 12 kết thúc ở ranh giới của một process — kiến trúc bảo vệ domain model bên trong một deployable. Chương này bước qua ranh giới đó. Ngay khi hệ thống của bạn có từ hai deployable trở lên (dù chỉ là API + worker, chưa cần tới microservices), một loạt định luật vật lý mới có hiệu lực: message có thể lặp, mất, đến trễ hoặc sai thứ tự; transaction không trải qua hai database; “lưu xong rồi publish” không còn là một hành động atomic. Đây là chương dài nhất của bộ tài liệu, vì đây là nơi phần lớn hệ thống production thật sự gãy — không phải ở chỗ model Entity hay Value Object, mà ở chỗ hai bounded context nói chuyện với nhau qua một đường mạng không đáng tin. Sau chương này là 14 - DDD trong Production.

Chương 12: DDD và Kiến trúc hệ thống

Thu, 09 Jul 2026 19:00:00 +0700

Vị trí trong lộ trình: Đến chương này, bạn đã có đầy đủ tactical patterns — Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event, Specification. Câu hỏi tiếp theo không còn là “mô hình hóa domain thế nào” mà là “đặt cái domain model đó vào đâu trong codebase, và bảo vệ nó bằng cách nào”. Chương này trả lời câu hỏi đó: từ layered architecture truyền thống, qua Hexagonal/Onion/Clean, đến cấu trúc thư mục cụ thể cho NestJS và Go, rồi mở rộng lên câu hỏi lớn hơn — Modular Monolith hay Microservices. Chương 13 sẽ tiếp tục với các pattern cho distributed systems.

Chương 11 — Specification: Business rule dạng điều kiện cũng xứng đáng có nhà

Thu, 09 Jul 2026 18:00:00 +0700

Vị trí trong bộ tài liệu: chương khép lại phần Tactical Design. Entity/Value Object (06) chứa rule của một object, Aggregate (07) giữ invariant khi ghi, Domain Service (09) chứa nghiệp vụ vắt qua nhiều object, Domain Event (10) lan truyền hậu quả. Còn một loại rule chưa có nhà: câu hỏi có/không về một object — “khách này có đủ điều kiện X không?”. Chương này ngắn hơn các chương trước, vì pattern nhỏ — nhưng nó hay bị dùng sai theo cả hai chiều: không dùng khi cần, và lạm dụng khi không cần.

Chương 10: Domain Event — Ghi lại những gì ĐÃ xảy ra, để phần còn lại của hệ thống tự lo

Thu, 09 Jul 2026 17:00:00 +0700

Vị trí chương này: Chương 9 kết thúc bằng một món nợ: PlaceOrderUseCase gọi events.publishAll(order.pullDomainEvents()) và hứa “chương 10 giải thích”. Email xác nhận, SMS cho khách Platinum, cộng điểm loyalty, trừ kho — tất cả đã bị đuổi ra khỏi transaction đặt hàng mà chưa nói rõ chúng đi đâu. Chương này trả món nợ đó. Domain Event cũng là cây cầu nối sang phần sau của tài liệu: không hiểu nó thì không đọc được chương 12 (kiến trúc), chương 13 (distributed systems), và toàn bộ các case study 15a/15b.

Chương 9: Domain Service và Application Service — Tách "nồi lẩu" Service ra đúng tầng

Thu, 09 Jul 2026 16:00:00 +0700

Vị trí chương này: Bạn đã đi qua Entity, Value Object (chương 6), Aggregate (chương 7), Repository và Factory (chương 8). Đến đây, mô hình domain của bạn đã có “xương sống”. Nhưng thực tế sẽ nhanh chóng ném vào mặt bạn một câu hỏi: có những nghiệp vụ không thuộc về bất kỳ Entity nào cả — nhét nó vào đâu? Chương này trả lời câu hỏi đó, và quan trọng hơn: mổ xẻ cái OrderService 500 dòng mà gần như mọi codebase NestJS/Go đều có, rồi tách nó ra từng lớp một. Đây là chương “bẩn tay” nhất từ đầu tài liệu đến giờ.

Chương 08 — Repository và Factory: Cửa khẩu giữa Domain và hạ tầng lưu trữ

Thu, 09 Jul 2026 15:00:00 +0700

Vị trí trong bộ tài liệu: chương thứ ba của Tactical Design. Chương 06 xây viên gạch (Entity, Value Object), chương 07 xây bức tường (Aggregate và ranh giới nhất quán). Chương này trả lời câu hỏi còn treo: aggregate được lấy ra và cất vào đâu, bằng cách nào, mà domain model không bị ORM và SQL xâm thực.

1. Problem Statement: Domain model chết đuối trong query

Một codebase NestJS điển hình sau 18 tháng:

Chương 07 — Aggregate và Aggregate Root: Consistency Boundary trong thế giới concurrent

Thu, 09 Jul 2026 14:00:00 +0700

Vị trí chương này: Đây là chương quan trọng nhất của toàn bộ Tactical Design — nếu chỉ được đọc kỹ một chương trong nửa sau tài liệu, hãy đọc chương này. Chương 06 cho chúng ta Entity và Value Object — công cụ bảo vệ tính đúng đắn của từng object riêng lẻ. Nhưng bug đắt nhất trong production hiếm khi nằm ở một object: nó nằm ở invariant xuyên nhiều object, bị xé rách bởi các request chạy đồng thời. Aggregate là câu trả lời của DDD cho đúng bài toán đó. Hiểu sai Aggregate thì Repository (chương 08), Domain Event (chương 10) và toàn bộ phần distributed systems (chương 13) sẽ sai theo.

Chương 6: Entity và Value Object — Hai viên gạch đầu tiên của Tactical Design

Thu, 09 Jul 2026 13:00:00 +0700

Vị trí chương này: Từ chương 1 đến chương 5, chúng ta đã đi qua Strategic Design — cách chia hệ thống thành Domain, Subdomain, Bounded Context và cách các context nói chuyện với nhau. Từ chương này trở đi, chúng ta bước vào Tactical Design: cách viết code bên trong một Bounded Context. Entity và Value Object là hai building block cơ bản nhất — mọi thứ khác (Aggregate ở chương 7, Repository ở chương 8, Domain Service ở chương 9) đều xây trên hai khái niệm này. Nếu bạn hiểu sai Entity/Value Object, toàn bộ phần còn lại của Tactical Design sẽ méo theo.

Chương 05 — Context Mapping: Bản Đồ Quyền Lực Giữa Các Bounded Context

Thu, 09 Jul 2026 12:00:00 +0700

Vị trí chương này trong chuỗi tài liệu: Ở chương 04, chúng ta đã vẽ xong ranh giới — mỗi Bounded Context có model riêng, ngôn ngữ riêng, team riêng. Nhưng ranh giới không có nghĩa là cô lập: Ordering vẫn phải biết giá từ Catalog, Shipping vẫn phải nhận đơn từ Ordering, và cả hệ thống vẫn phải nói chuyện với core banking 20 năm tuổi của đối tác. Chương này trả lời câu hỏi: các context quan hệ với nhau như thế nào — về mặt kỹ thuật, và quan trọng hơn, về mặt tổ chức và quyền lực? Đây là chương khép lại phần strategic design; từ chương 06 trở đi chúng ta đi vào tactical design — xây dựng model bên trong một context.

Chương 04 — Bounded Context: Ranh Giới Ngữ Nghĩa Của Model

Thu, 09 Jul 2026 11:00:00 +0700

Vị trí chương này trong chuỗi tài liệu: Ở chương 02, chúng ta đã mổ xẻ domain và subdomain — tức là bài toán mà business đang phải giải. Ở chương 03, chúng ta thống nhất rằng ngôn ngữ chung giữa engineer và domain expert là nền móng của mọi model tốt. Chương này trả lời câu hỏi tiếp theo, và cũng là câu hỏi quan trọng bậc nhất của DDD chiến lược: ngôn ngữ đó, model đó, có hiệu lực đến đâu? Ranh giới của nó nằm ở chỗ nào? Nếu bạn chỉ được đọc một chương duy nhất trong toàn bộ phần strategic design, hãy đọc chương này. Chương kế tiếp — 05: Context Mapping — sẽ nói về chuyện gì xảy ra giữa các ranh giới đó.

Chương 03 — Ubiquitous Language: Ngôn ngữ chung là nền móng, không phải phụ kiện

Thu, 09 Jul 2026 10:00:00 +0700

Vị trí trong bộ tài liệu: chương cuối của phần Foundations. Chương 01 chỉ ra business complexity là kẻ thù chính; chương 02 dạy cách chia domain để phân bổ nguồn lực. Chương này trả lời câu hỏi nền tảng hơn cả hai: làm sao để những gì team hiểu về nghiệp vụ không bị bóp méo trên đường đi từ cuộc họp vào code. Không có chương này, mọi pattern phía sau đều xây trên cát.

Chương 02 — Domain và Subdomain: Bản đồ chiến lược trước khi viết dòng code đầu tiên

Thu, 09 Jul 2026 09:00:00 +0700

Vị trí trong bộ tài liệu: Chương trước (01 — Tại sao DDD ra đời) đã xác lập rằng business complexity là kẻ thù chính và DDD là phương pháp tư duy để quản lý nó. Chương này trả lời câu hỏi chiến lược đầu tiên mà mọi Architect phải trả lời trước khi chọn công nghệ, vẽ kiến trúc hay tạo class: độ phức tạp nghiệp vụ nằm ở đâu trong doanh nghiệp, phần nào tạo ra tiền, và phần nào đáng đầu tư kỹ sư giỏi nhất? Đây là nội dung Strategic Design thuần túy — chưa có một dòng Entity hay Aggregate nào. Chương tiếp theo: 03 — Ubiquitous Language. Mục lục: 00-muc-luc.md.

Chương 01 — Tại sao DDD ra đời: Business Complexity là kẻ thù thật sự

Thu, 09 Jul 2026 08:00:00 +0700

Vị trí trong bộ tài liệu: Đây là chương mở đầu của bộ tài liệu Domain-Driven Design (xem 00-muc-luc.md). Trước khi nói về Bounded Context, Aggregate hay Domain Event, chúng ta phải trả lời câu hỏi nền tảng nhất: DDD sinh ra để giải quyết vấn đề gì, và tại sao những cách làm quen thuộc — database-first, CRUD, transaction script — lại thất bại? Nếu bạn không đồng ý với chương này, mọi chương sau đều vô nghĩa với bạn. Chương tiếp theo: 02-domain-va-subdomain.md.

Domain-Driven Design — Bộ tài liệu chuyên sâu

Thu, 09 Jul 2026 07:00:00 +0700

Tài liệu dành cho Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect và Software Architect. Viết bằng tiếng Việt, giữ nguyên thuật ngữ chuyên ngành (Domain, Bounded Context, Aggregate, Entity, Value Object, Domain Event, Repository, Ubiquitous Language…). Code mẫu dùng TypeScript (NestJS) và Go, mỗi khái niệm đều được đối chiếu với cách làm phổ biến trong framework để chỉ ra những điểm dễ hiểu sai.

Tài liệu này viết theo triết lý nào

Không chương nào mở đầu bằng định nghĩa. Mọi khái niệm đi theo mạch: vấn đề business có thật → vì sao cách làm truyền thống thất bại → bản chất của lời giải → cách hoạt động → điểm mạnh, điểm yếu, trade-off → cân nhắc production → anti-pattern → khi nào KHÔNG nên dùng. Mỗi kết luận kỹ thuật đều phải trả lời: tại sao? đánh đổi gì? không áp dụng thì sao? áp dụng sai thì hậu quả gì? Và xuyên suốt: DDD không phải một bộ class — nó là phương pháp tư duy để quản lý sự phức tạp của business; tài liệu không thần thánh hóa nó, mà chỉ rõ chỗ nào nó đáng tiền và chỗ nào nó là gánh nặng.