Architecture

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. ...

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ư. ...

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. ...

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ể. ...

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. ...

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. ...

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. ...

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. ...

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ờ. ...

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: ...

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. ...

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. ...

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. ...

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 đó. ...

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. ...

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. ...

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. ...

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. ...

← Chương trước | Mục lục | Chương sau → Đây là chương quan trọng nhất của toàn bộ tài liệu. Mọi kiến thức về giao thức, message broker, resilience pattern ở các chương trước chỉ thực sự có giá trị khi bạn đứng trước một dashboard đỏ rực lúc 2 giờ sáng và phải trả lời ba câu hỏi: chuyện gì đang xảy ra, tại sao, và làm gì ngay bây giờ. ...

← Chương trước | Mục lục | Chương sau → 15.1. Business problem: khi công ty vượt qua biên giới một region Hãy bắt đầu từ một tình huống có thật ở hầu hết các công ty tăng trưởng nhanh. Công ty của bạn khởi đầu với toàn bộ hệ thống đặt tại một region — giả sử us-east-1 (Virginia). Ba năm sau, business mở rộng ra ba châu lục: Bắc Mỹ, châu Âu, và Đông Nam Á. Ngay lập tức, ba loại áp lực xuất hiện cùng lúc, và cả ba đều không giải quyết được bằng cách “tối ưu code”: ...

← Chương trước | Mục lục | Chương sau → Mở đầu: Bài toán kinh doanh Hãy bắt đầu từ một câu chuyện quen thuộc. Công ty của bạn có một monolith, 50 developer, deploy 1 lần/tuần. Mỗi lần deploy là một “sự kiện”: freeze code từ thứ Tư, QA regression 2 ngày, deploy đêm thứ Sáu, và cả team on-call cuối tuần. Feature nhỏ nhất cũng mất 2 tuần để ra production vì phải xếp hàng chung chuyến tàu release. Ban lãnh đạo hỏi: “Đối thủ ship feature mỗi ngày, tại sao chúng ta mất 2 tuần?” ...

← Chương trước | Mục lục | Chương sau → 12.1. First principles: partial failure là trạng thái bình thường Trong monolith, một lời gọi hàm hoặc thành công hoặc ném exception — và cả hai đều xảy ra trong cùng một process, cùng một số phận. Khoảnh khắc bạn tách hàm đó ra sau một network call, bạn nhận về một tập kết quả hoàn toàn mới: thành công, thất bại, và mọi trạng thái lửng lơ ở giữa — request đến nơi nhưng response thất lạc, request đang xếp hàng ở đâu đó và sẽ được xử lý sau 30 giây nữa, downstream đã xử lý xong nhưng bạn đã bỏ đi. ...

← Chương trước | Mục lục | Chương sau → 11.1. Vì sao API design là quyết định khó đảo ngược nhất Bắt đầu từ một sự thật mà mọi engineer đều học được theo cách đau đớn: code là tài sản riêng của bạn, còn API là hợp đồng công khai với người khác. Bạn có thể refactor toàn bộ internal implementation vào thứ Ba tuần sau mà không ai hay biết. Nhưng một field đã xuất hiện trong response, một URI đã có người gọi, một status code đã có người viết if để bắt — những thứ đó không còn thuộc về bạn nữa. Chúng thuộc về mọi consumer đang phụ thuộc vào chúng. ...

← Chương trước | Mục lục | Chương sau → 1. Problem Statement Chín chương vừa qua đã mổ xẻ từng công nghệ. Bây giờ là câu hỏi mà mọi architect phải trả lời hàng tuần, và là câu hỏi bị trả lời sai nhiều nhất: “Service A cần nói chuyện với Service B / với client. Dùng cái gì?” Cách câu hỏi này thường bị trả lời sai trong thực tế: ...

← Chương trước | Mục lục | Chương sau → 1. Problem Statement Hãy bắt đầu bằng một bài toán thật, không phải định nghĩa sách giáo khoa. Bạn vận hành một nền tảng thương mại điện tử. Mỗi hành động của người dùng — xem sản phẩm, thêm vào giỏ, tìm kiếm, click banner — sinh ra một event. Ở quy mô 10 triệu người dùng hoạt động, hệ thống của bạn sinh 2–5 triệu event mỗi giây vào giờ cao điểm. Và đây là danh sách những bên muốn tiêu thụ dòng event đó: ...

← Chương trước | Mục lục | Chương sau → 1. Problem Statement Hãy bắt đầu từ một luồng nghiệp vụ mà mọi hệ thống e-commerce đều có: khách hàng đặt hàng thành công. Khi đơn hàng được tạo, hệ thống phải làm ít nhất bốn việc: Gửi email xác nhận cho khách. Cộng điểm tích lũy (loyalty). Cập nhật tồn kho (inventory). Đẩy dữ liệu sang hệ thống analytics. Cách tiếp cận ngây thơ nhất — và cũng là cách hầu hết các hệ thống bắt đầu — là gọi synchronous tất cả trong cùng một request: ...

← Chương trước | Mục lục | Chương sau → 1. Problem Statement Ba bài toán rất phổ biến có chung một hình dạng: Dashboard giá / telemetry: server đẩy giá mới, số liệu mới xuống hàng nghìn màn hình. Client chỉ nhìn, không gửi gì (ngoài vài thao tác lọc hiếm hoi qua REST). Notification feed: “bạn có comment mới” — server phát, client nhận. LLM token streaming: model sinh token, server đẩy từng token xuống UI ngay khi có. Client gửi đúng một prompt lúc đầu (qua POST), sau đó chỉ nhận. Điểm chung: dữ liệu chảy một chiều, server → client. Chiều ngược lại hoặc không tồn tại, hoặc thưa thớt tới mức một HTTP request bình thường phục vụ tốt. ...

← Chương trước | Mục lục | Chương sau → 1. Problem Statement Bạn đang xây một collaboration app: chat nhóm, cursor tracking, comment realtime. Yêu cầu nghiệp vụ rất rõ ràng: khi user A gõ một tin nhắn, user B phải thấy nó trong vòng dưới 200ms; đồng thời client của B cũng liên tục gửi trạng thái của chính nó lên server (typing indicator, cursor position). Nghĩa là dữ liệu chảy cả hai chiều, liên tục, với tần suất cao và độ trễ thấp. ...

← Chương trước | Mục lục | Chương sau → 1. Problem Statement Hãy bắt đầu từ một hệ thống thật. Bạn đang vận hành một nền tảng thương mại điện tử với khoảng 200 internal service. Mỗi request từ người dùng — ví dụ “đặt hàng” — kích hoạt một chuỗi gọi nội bộ: api-gateway → order-service → inventory-service → pricing-service → promotion-service → payment-service → notification-service. Fan-out trung bình 1 request bên ngoài thành 15–30 lời gọi nội bộ. Ở mức 5.000 request/giây từ phía người dùng, hệ thống nội bộ đang xử lý hơn 100.000 lời gọi service-to-service mỗi giây. ...

← Chương trước | Mục lục | Chương sau → 1. Problem Statement Hãy bắt đầu bằng một tình huống mà gần như mọi team backend phục vụ mobile app đều gặp phải. Công ty bạn có một mobile app thương mại điện tử. App có màn hình Home, màn hình Profile, màn hình Order History, màn hình Order Detail. Backend đã có sẵn một bộ REST API được thiết kế “chuẩn resource-oriented”: ...