sys-analysis-design/sa-output/e-commerce/02-architecture/adr/ADR-012_ranh-gioi-nhom-trien-khai-theo-domain.md

ADR-012 — Ranh giới nhóm triển khai (deployment boundary): Nhóm Giao dịch / Nhóm Hỗ trợ / Payment tách biệt

Tên file: adr/ADR-012_ranh-gioi-nhom-trien-khai-theo-domain.md

Status	Proposed
Date	2026-09-15
Người quyết	SA + Tech Lead (cấu trúc/ranh giới service — decision-radar.md §5)
Người đề xuất	SA (qua skill sa-2-architecture, hoạt động adr)
Điểm radar	~7/10
Supersedes	—
Superseded by	—
Liên quan	ASR-014 · CON-05 · OQ-010 · OQ-026 · ASM-19 · ASM-22 · ASM-23 · ADR-001 · SAD §4.1, §7

⚠️ ADR bất biến sau khi Accepted. Muốn đổi quyết định thì viết ADR mới có Supersedes: ADR-012 và đổi trạng thái bản cũ thành Superseded by.

---

1. Bối cảnh

ADR-001 đã chọn modular monolith (P2) với 2–3 nhóm triển khai ECS Fargate thay vì ~10 service độc lập. ADR này là quyết định cụ thể tiếp theo: module nào nằm nhóm nào — khác ADR-001 ở chỗ đó là quyết định "monolith hay không", còn đây là "ranh giới cụ thể bên trong monolith". ASR-014 ghi nhận việc gom module vào nhóm phải phản ánh đúng năng lực đội thi công thật, không chỉ theo giả định "team MVP chuẩn" (DEC-02). Hai câu hỏi mở trực tiếp ảnh hưởng ADR này: OQ-010 (số đội thi công thật) và OQ-026 (SAD phát hiện lệch mức chi tiết giữa "2 nhóm ECS service riêng" và cách TCO §3.2 tính gộp compute thành 1 dòng).

Ràng buộc đang chi phối:

Nguồn	Nội dung
ASR-014	Ranh giới nhóm triển khai phải khớp năng lực đội thi công thật
CON-05	Team giả định "team MVP chuẩn" (DEC-02), chưa xác nhận thật
OQ-010	Tech Lead chưa xác nhận đội thi công thật
OQ-026	TCO §3.2 tính gộp compute — chưa rõ là 1 hay 2 ECS service thật
ASM-22	Identity & Access xếp vào Nhóm Giao dịch — suy luận từ ASR-010/011, chưa Tech Lead xác nhận

Cái đã biết chắc / cái còn là giả định:

Điều	🟢 Đã kiểm chứng / 🔴 Giả định	Bằng chứng
Payment phải tách biệt hoàn toàn khỏi 2 nhóm còn lại	🟢 Đã kiểm chứng	ADR-002 (độc lập với ADR này)
Nhóm Giao dịch (Catalog & Inventory, Cart & Order) cần scale nhanh hơn Nhóm Hỗ trợ	🟡 Ước lượng có cơ sở	DRV-04, OPT §3 — chưa có số đo thật sau go-live
Identity & Access thuộc Nhóm Giao dịch (không phải nhóm riêng/Nhóm Hỗ trợ)	🔴 Giả định (ASM-22)	Suy từ ASR-010/011 ("nhóm giao dịch cốt lõi" bao gồm Identity cho HA/DR) — OPT §3 không nói rõ
TCO §3.2 phản ánh đúng 2 ECS service riêng (không phải 1 service gộp)	🔴 Giả định (ASM-23)	OQ-026 — chưa Tech Lead/Ops xác nhận

2. Phương án đã cân nhắc

PA-1 — 1 nhóm ECS duy nhất cho toàn bộ monolith (không tách Nhóm Giao dịch/Nhóm Hỗ trợ)

Mô tả	Toàn bộ 9 module (trừ Payment) chạy trong 1 ECS Fargate service duy nhất, scale chung
Ưu	Đơn giản nhất — chỉ 2 đơn vị triển khai (1 monolith + 1 Payment); ít cấu hình network/scaling riêng
Nhược	Không thể scale-out riêng Catalog/Cart&Order khi flash sale mà không kéo theo cả Nhóm Hỗ trợ — lãng phí tài nguyên hoặc thiếu tài nguyên đúng lúc cần; vi phạm DRV-04 một phần (mục tiêu chịu tải đỉnh của riêng luồng giao dịch)
Chi phí đảo ngược	Trung bình — tách thành 2 nhóm sau này cần cấu hình lại network/scaling policy, nhưng không cần migrate dữ liệu (cùng schema-per-module)

PA-2 — 2 nhóm ECS: Nhóm Giao dịch (Identity, Catalog, Cart&Order) / Nhóm Hỗ trợ (còn lại) (chọn tạm)

Mô tả	Theo OPT §3 P2 — Nhóm Giao dịch gồm Identity & Access, Catalog & Inventory, Cart & Order; Nhóm Hỗ trợ gồm Seller Management, Commission & Payout, Promotion & Loyalty, Review, Notification, Shipping & Fulfillment; mỗi nhóm là 1 ECS Fargate service riêng, scale độc lập
Ưu	Cho phép scale riêng Nhóm Giao dịch khi flash sale mà không ảnh hưởng Nhóm Hỗ trợ (đáp ứng DRV-04); khớp đề xuất đã duyệt từng phần ở OPT §3/DEC-06
Nhược	Vị trí Identity & Access trong Nhóm Giao dịch là suy luận của SA (ASM-22), chưa được Tech Lead xác nhận trực tiếp; OQ-026 cho thấy TCO chưa rõ có tính đúng 2 service riêng hay không — nếu TCO thực ra tính 1 service, phương án này phát sinh chi phí chưa được duyệt
Chi phí đảo ngược	Trung bình — đổi thành viên giữa 2 nhóm (VD chuyển Identity sang Nhóm Hỗ trợ) là thay đổi cấu hình + CI/CD, không phải viết lại code (nhờ ranh giới module đã có ở ADR-001)

PA-3 — 3 nhóm ECS: tách riêng Identity & Access thành nhóm thứ ba (ngoài Nhóm Giao dịch/Nhóm Hỗ trợ)

Mô tả	Identity & Access là một ECS service riêng biệt, không thuộc Nhóm Giao dịch hay Nhóm Hỗ trợ, vì đây là dịch vụ nền tảng được cả hai nhóm gọi tới
Ưu	Tách bạch rõ ràng vai trò "hạ tầng xác thực dùng chung" khỏi logic nghiệp vụ Catalog/Cart&Order; có thể scale/HA riêng cho Identity mà không phụ thuộc tải của Catalog
Nhược	Thêm một đơn vị triển khai thứ 4 (ngoài Payment) — tăng chi phí vận hành so với PA-2; chưa có trong ước lượng TCO §3.2 nào (chỉ có "monolith" + Payment)
Chi phí đảo ngược	Thấp — tách Identity ra là thu hẹp phạm vi 1 service, ít rủi ro hơn gộp lại

Bảng so sánh

Tiêu chí	PA-1 (1 nhóm)	PA-2 (2 nhóm, Identity ở Nhóm Giao dịch)	PA-3 (3 nhóm, Identity riêng)
Scale riêng Nhóm Giao dịch khi flash sale (DRV-04)	❌	✅	✅
Khớp OPT §3/DEC-06 đã duyệt từng phần	❌	✅	🔶 Gần khớp, thêm 1 nhóm
Khớp TCO §3.2 hiện tại (chưa rõ, OQ-026)	✅ (nếu TCO tính 1 service)	🔶 Chờ xác nhận	❌ Chưa có trong TCO
Số đơn vị triển khai	2	3	4

3. Quyết định

Đề xuất PA-2 — 2 nhóm ECS: Nhóm Giao dịch (Identity & Access, Catalog & Inventory, Cart & Order) / Nhóm Hỗ trợ (5 module còn lại), cộng Payment tách biệt.

🔴 Đây là quyết định tạm, chưa đủ điều kiện Accepted — theo ASM-22/ASM-23 và OQ-010/ OQ-026 vẫn mở. Giữ PA-2 làm hướng đi (nhất quán với OPT §3/DEC-06/SAD §4.1) cho tới khi Tech Lead/Ops xác nhận.

Vì sao đề xuất PA-2: Cân bằng giữa khả năng scale riêng Nhóm Giao dịch (DRV-04, loại PA-1) và không phát sinh thêm chi phí vận hành chưa có trong TCO (loại PA-3, chờ xác nhận thêm ngân sách nếu cần).

Phạm vi áp dụng: Toàn bộ 9 module ngoài Payment.

Điều kiện chuyển Proposed → Accepted

Điều kiện	Ai xác nhận	Trạng thái hiện tại
OQ-010 — Tech Lead xác nhận số đội thật khớp (hoặc đủ để vận hành) 2–3 nhóm triển khai	Tech Lead	Mở
OQ-026 — Tech Lead/Ops xác nhận TCO §3.2 tính đúng 2 ECS service riêng (không phải 1 gộp)	Tech Lead + Ops/SRE	Mở
OQ-027 — Tech Lead xác nhận vị trí Identity & Access (Nhóm Giao dịch hay riêng/Nhóm Hỗ trợ)	Tech Lead	Mở

4. Phương án bị loại và lý do

Phương án	Loại vì	Gắn với	Điều kiện nào thì xét lại
PA-1 — 1 nhóm ECS duy nhất	Không đáp ứng nhu cầu scale riêng Nhóm Giao dịch khi flash sale	DRV-04	Nếu OQ-026 xác nhận TCO thực ra chỉ tính 1 service (không đủ ngân sách cho 2 nhóm riêng) — quay lại PA-1 và ghi nhận giảm điểm tiêu chí "Đáp ứng DRV Must" đã chấm ở OPT §4
PA-3 — 3 nhóm, Identity riêng	Chưa có trong TCO §3.2, tăng chi phí vận hành chưa được PO duyệt	TCO §3.2, CON-01	Nếu Tech Lead xác nhận Identity cần HA/scale độc lập khỏi Catalog/Cart&Order (VD do tải xác thực rất khác biệt) và PO duyệt thêm chi phí — trình bảng đánh đổi

5. Hệ quả

Hệ quả tích cực

• Cho phép scale riêng Nhóm Giao dịch khi flash sale mà không lãng phí tài nguyên cho Nhóm Hỗ trợ
• Nhất quán với hướng đi đã duyệt từng phần ở OPT §3/DEC-06

Hệ quả tiêu cực phải sống chung

• Vị trí Identity & Access vẫn là giả định (ASM-22) — rủi ro phải đổi cấu hình khi Tech Lead xác nhận khác
• Nếu OQ-026 xác nhận TCO chưa tính đủ chi phí 2 service riêng, cần cập nhật TCO trước khi ADR này có thể Accepted

Cái quyết định này khoá lại

Muốn đổi về sau thì	Tốn
Đổi thành viên giữa Nhóm Giao dịch/Nhóm Hỗ trợ sau khi team đã quen vận hành theo ranh giới cũ	Tái tổ chức CI/CD + on-call — ước 1-3 tuần tuỳ mức độ đổi

Việc phát sinh

Việc	Chủ	Hạn	Ghi ở đâu
Tech Lead xác nhận OQ-010 (số đội thật)	Tech Lead	Trước khi Accepted	00-index/OQ_e-commerce.md
Tech Lead/Ops xác nhận OQ-026 (khớp TCO)	Tech Lead + Ops/SRE	Trước khi Accepted, trước hoạt động inf chốt	00-index/OQ_e-commerce.md
Tech Lead xác nhận OQ-027 (vị trí Identity)	Tech Lead	Trước khi Accepted	00-index/OQ_e-commerce.md

6. Cách kiểm chứng quyết định này được tuân thủ

Cách kiểm	Công cụ	Chạy ở đâu	FIT
Đúng 2 ECS Fargate service (Nhóm Giao dịch, Nhóm Hỗ trợ) + 1 Payment tồn tại trong hạ tầng	Kiểm tra hạ tầng (Terraform plan review)	CI/CD	FIT-16 (ứng viên)
Module thuộc đúng nhóm theo bảng CMP-nn cột "Nhóm triển khai" (SAD §4.1)	Review kiến trúc định kỳ	GĐ3 (DREV)	—

7. Điều kiện xét lại

Dấu hiệu	Ngưỡng	Ai theo dõi
OQ-010 trả lời team thật khác biệt đáng kể so với giả định	Số BE thật < 50% hoặc > gấp đôi giả định DEC-02	Tech Lead
OQ-026 xác nhận TCO chỉ tính 1 service (không đủ ngân sách 2 nhóm)	Khi có xác nhận	PO/Tech Lead
Tải thật cho thấy Identity cần scale độc lập khỏi Catalog/Cart&Order	Dữ liệu production sau go-live	SRE

8. Tham chiếu

• POC: Không áp dụng
• Bài đo: FIT-16 (ứng viên GĐ3)
• Tài liệu ngoài: OPT_e-commerce_v1.0.md §3 (P2), SAD_e-commerce_v1.0.md §4.1, §7, §10 (ASM-22/23), §11 (OQ-026/027)
• Thảo luận: ASR_e-commerce_v1.0.md §B2 ASR-014

9. Review log (không đổi Status)

Ngày	Người review	Vai trò	Quyết định	Lý do chưa chuyển Accepted
2026-09-15	Điều phối dự án (thay mặt Tech Lead, chế độ chạy thử)	Tech Lead (ký thay, ngoại lệ DEC-01)	Reviewed (Proposed giữ nguyên) — nội dung đủ làm cơ sở thiết kế tiếp (icd/dat/sec/inf/fail)	Chờ Tech Lead + Ops/SRE xác nhận OQ-010/OQ-026/OQ-027

Đây là ghi nhận review nội dung, không phải "sign" theo nghĩa gate: Status giữ nguyên Proposed. Xem 00-index/ADL_e-commerce.md (Change Log — Review 2026-09-15) và ADL §8 "Việc phải làm" cho điều kiện chuyển Accepted. Confidence tổng thể của lượt review: 🔴 — AG2 chưa ký.