save

sa-output/e-commerce/02-architecture/SAD_e-commerce_v1.0.md

@@ -0,0 +1,705 @@
+# SAD — Solution Architecture Document — e-commerce
+
+| | |
+|---|---|
+| **Version** | 1.3 |
+| **Date** | 2026-09-15 |
+| **Author** | SA (skill sa-2-architecture, chế độ `go`, hoạt động `sad`) |
+| **Status** | 🟡 Draft *(duyệt từng phần — xem `Approved by`; AG2 cần cả ba vai trò (Tech Lead/Security/Ops-SRE) ký, mới có một chữ ký thay có điều kiện — **chưa đủ điều kiện chuyển `🔵 Approved`**)* |
+| **Approved by** | Tech Lead: **Điều phối dự án** (uỷ quyền, chế độ chạy thử — ký thay theo ngoại lệ `DEC-01`, **không phải chữ ký Tech Lead thật**) — duyệt **từng phần** bản v1.0 · 2026-09-15: chấp nhận C4 Context/Container/Component (Cart & Order), deployment view, bảng `CMP-01…15`, ma trận `ASR→CMP` đủ 15/15, 17 `IF-nn` ứng viên cho `ICD` *(sửa từ số đếm sai "22" ở v1.2 — xem `OQ-029`, `ICD §0.1`, Change Log v1.2)*, 12 chỗ chờ `ADR-001…012` (không `ADR` nào được viết ở lượt này). Chốt **TẠM** `OQ-026` (P2 có 2 ECS Fargate service riêng — Nhóm Giao dịch/Nhóm Hỗ trợ — để scale độc lập, `TCO §3.2` giữ nguyên tới khi hoạt động `inf` xác nhận, theo `ASM-23`) và `OQ-027` (Identity & Access thuộc Nhóm Giao dịch, theo `ASM-22`) làm hướng đi tạm cho hoạt động `icd`/`dat`/`sec`/`inf`/`fail` kế tiếp — **`OQ-026`/`OQ-027` giữ nguyên MỞ**, chờ Tech Lead/Ops thật xác nhận, không coi là đã đóng. Ký thay Tech Lead theo ngoại lệ `DEC-01` (SA) — **không phải chữ ký Tech Lead thật**. · Security: — *(chưa ký)* · Ops/SRE: — *(chưa ký)* — AG2 cần cả ba cùng ký; tài liệu này **vẫn chưa qua AG2**, còn xa vì `ICD`/`DAT`/`SEC`/`INF`/`FAIL` (hoạt động 4–8) và mọi `ADR` (hoạt động 9) chưa chạy. `OQ-004` (tính hợp lệ ký thay) vẫn mở. `Confidence` **giữ nguyên** 🔴 — duyệt từng phần không phải bằng chứng nguồn mới, không nâng `Confidence`. Status **giữ** 🟡 Draft — AG2 chưa đủ ba chữ ký thật/hợp lệ. Ghi thêm `DEC-16`. **Lưu ý v1.2 (2026-09-15):** §4/§6/§7 vừa được sửa lỗi nhất quán (phân loại
+`IF-021` cross-network, đếm lại `IF-nn` 22→17) theo yêu cầu người duyệt và phát hiện của `ICD`
+(`OQ-028`/`OQ-029`) — đây là sửa lỗi tài liệu, **không phải** nội dung kiến trúc mới; chữ ký nêu
+trên chỉ áp dụng cho nội dung **trước khi sửa**, §4/§6/§7 bản v1.2 **chưa được Tech Lead/Security/
+Ops ký lại**. **Lưu ý v1.3 (2026-09-15):** §6.1 (sequence checkout) và §8 (bảng ADR) vừa được sửa
+theo `ADR-013` (`Proposed`, bất đồng bộ hoá bước khởi tạo thanh toán — quyết định Lựa chọn B của
+`OQ-034`/`DEC-22`) — đây **là** nội dung kiến trúc mới (đổi luồng checkout đồng bộ→có nhánh bất
+đồng bộ), **không phải** sửa lỗi tài liệu như v1.2; chữ ký nêu trên **không** áp dụng cho §6.1/§8
+bản v1.3 — cần Tech Lead + PO **thật** xác nhận `ADR-013` trước khi coi §6.1/§8 là đã duyệt. |
+| **Source** | `02-architecture/ASR_e-commerce_v1.0.md` v1.0 (toàn bộ `ASR-001…015`, §B2, §D) · `02-architecture/QAS_e-commerce_v1.0.md` v1.0 (§A3, §A4 xung đột) · `01-context/OPT_e-commerce_v1.0.md` §1, §3 (P2), §9 · `01-context/CTX_e-commerce_v1.0.md` §2 (`DRV`), §3 (`CON`), §4.2 (đối tác ngoài) · `01-context/TCO_e-commerce_v1.0.md` §3.2 (P2, kịch bản A/B) · `01-context/ARISK_e-commerce_v1.0.md` §3, §6 (`POC-01/02`) · `02-architecture/FAIL_e-commerce_v1.0.md` v1.1 §1.2 (ngân sách timeout, phát hiện vượt `QAS-002`) · `02-architecture/adr/ADR-013_bat-dong-bo-hoa-khoi-tao-thanh-toan.md` (mới, `Proposed`) · `00-index/OQ_e-commerce.md` v1.18 (`OQ-034`, `DEC-22`) · `00-index/DEC_e-commerce.md` v1.20 (`DEC-22`, `DEC-23`) · `ba-output/e-commerce/02-analysis/PROCESS_CartCheckout_v1.0.md` (luồng B1–B9) · `ba-output/e-commerce/02-analysis/IMPACT_CartCheckout_v1.0.md` §1.5 (tích hợp) · `ba-output/e-commerce/03-specification/API_US002-003_v1.0.md` (contract đề xuất Cart) · `e-commerce/docs/sections/03-kien-truc.md` §3.1 (**chỉ tái dùng danh sách module/domain và tích hợp ngoài — KHÔNG kế thừa kiểu kiến trúc ~10 microservices, đó là P1 đã bị loại ở `OPT §5`**) · `e-commerce/docs/sections/04-api-design.md` §4.1 (danh sách endpoint tham khảo) |
+| **Scope** | Toàn sàn e-commerce theo phương án **P2** (modular monolith + managed AWS, tách riêng Payment Service — `DEC-06`/`ASR-001`, **chưa** có `ADR-001` chính thức, xem §8). Chi tiết nhất: module **Giỏ hàng & Checkout** (US-002/003, `BR-CART-01…09`, `RBAC` `ROLE-01/02`). Đây là hoạt động 3/9 của `sa-2-architecture` — **không** viết `ADR`/`ICD`/`DAT`/`SEC`/`INF`/`FAIL` ở lượt này; đánh dấu rõ chỗ chờ từng hoạt động đó. |
+| **Confidence** | 🔴 Giả định chưa xác minh — theo yêu cầu điều phối, tiếp nối `Confidence` 🔴 của `QAS`/`ASR`. AG1 chưa có chữ ký PO/Tech Lead thật (`OQ-004` mở); `POC-01`/`POC-02` chưa chạy; `ADR-001` (kiểu kiến trúc tổng thể) chưa tồn tại — tài liệu này **giả định trước** kết luận của `ADR-001` (P2) để có thể vẽ C4, đúng theo hướng đã duyệt từng phần ở `DEC-06`/`DEC-14`, nhưng bản thân quyết định đó vẫn `Proposed`, chưa `Accepted`. Mọi con số hạ tầng ở §7 kế thừa `TCO §3.2` nguyên trạng — không tự đổi khi phát hiện lệch (xem `OQ-026`). |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | ADR |
+|---|---|---|---|---|
+| 1.0 | 2026-09-15 | SA (qua skill sa-2-architecture, chế độ `go`, hoạt động `sad`) | Bản đầu — hoạt động 3/9 của `sa-2-architecture`. Dựng C4 Context (4 actor + 5 hệ ngoài), C4 Container (Mermaid, legend theo `D4`), C4 Component cho container "Nhóm Giao dịch" (chi tiết Cart & Order — đúng yêu cầu "chi tiết nhất cho Giỏ hàng & Checkout"), 2 sequence diagram (Checkout, Webhook thanh toán + đối soát), deployment view AWS `ap-southeast-1` đối chiếu `TCO §3.2` (phát hiện 1 điểm lệch mức chi tiết — ghi `OQ-026`, không tự đổi số `TCO`). Bảng `CMP-01…15` (15 component, ma trận `ASR-001…015` × `CMP` đủ 15/15, không CMP mồ côi), danh sách 17 `IF-nn` ứng viên cho `ICD` (hoạt động 4) *(số gốc "22" là đếm nhầm — sửa ở v1.2, xem `OQ-029`)*, bảng thực thể dữ liệu sở hữu ứng viên cho `DAT` (hoạt động 5), bảng phụ thuộc vượt ranh giới process ứng viên cho `FAIL` (hoạt động 8). Đánh dấu 12 chỗ chờ `ADR-001…012` (không viết `ADR` nào — đúng yêu cầu điều phối). Không sửa `QAS`/`ASR` đã duyệt từng phần. Thêm `OQ-026/027`, `ASM-22/23`. Ghi `DEC-15` (tiếp nối `DEC-01…14`, ngoại lệ gate tiếp tục GĐ2 hoạt động `sad`). `Confidence` 🔴 toàn bộ. | — *(chưa viết ADR)* |
+| 1.0 | 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ **sign/approve** | Duyệt **từng phần**: chấp nhận C4 Context/Container/Component, deployment view, bảng `CMP-01…15`, ma trận `ASR→CMP` đủ 15/15, 17 `IF-nn` ứng viên *(sửa từ "22" ở v1.2 — xem `OQ-029`)*, 12 chỗ chờ `ADR`. Chốt **TẠM** `OQ-026` (2 ECS Fargate service riêng theo Nhóm Giao dịch/Nhóm Hỗ trợ, `TCO §3.2` giữ nguyên tới khi `inf` xác nhận, `ASM-23`) và `OQ-027` (Identity & Access thuộc Nhóm Giao dịch, `ASM-22`) làm hướng đi tạm — cả hai **giữ nguyên mở**, chờ Tech Lead/Ops thật xác nhận. Không đổi nội dung chuyên môn. Security/Ops chưa ký; `OQ-004` mở; `Confidence` giữ 🔴; Status giữ 🟡 Draft; AG2 **chưa** ký. Ghi thêm `DEC-16`. | `DEC-16` |
+| 1.1 | 2026-09-15 | SA (qua skill sa-2-architecture, chế độ `go`, hoạt động `adr`) | **Chỉ cập nhật §8** (bảng "Quyết định kiến trúc đã ghi") — thay cột "*Chưa viết*" bằng đường dẫn file thật của 12 `ADR-001…012` vừa được viết (tất cả `Status: Proposed`, radar/điều kiện POC giữ nguyên không đổi so với bảng ứng viên đã duyệt từng phần ở `DEC-14`/`DEC-16`). Không sửa bất kỳ nội dung chuyên môn nào khác của `SAD` (C4, `CMP`, deployment view, `OQ`, `ASM` giữ nguyên như v1.0, đã qua duyệt từng phần `DEC-16`). Ghi thêm `DEC-17`. `Confidence` giữ 🔴 — việc link file không phải bằng chứng nguồn mới. | `DEC-17` |
+| 1.2 | 2026-09-15 | SA (qua skill sa-2-architecture, chế độ `go`, hoạt động `sad`) | **Sửa nhất quán theo phát hiện `ICD` (`OQ-028`/`OQ-029`), người duyệt yêu cầu 2026-09-15** — sửa lỗi tài liệu, không tạo nội dung kiến trúc mới, không đổi `CMP`. (1) `IF-021` (Cart&Order → Promotion&Loyalty): sửa mọi mô tả từ "internal call cùng process" thành **cross-network REST giữa 2 ECS Fargate service riêng** (Nhóm Giao dịch ↔ Nhóm Hỗ trợ, theo `OQ-026`/`ASM-23` và `OQ-028`/`ASM-24` đã chốt TẠM ở `ICD`) — sửa ở legend §4, thêm footnote §4.1, bảng bước §6.1, bảng phụ thuộc §6.3, bổ sung cạnh mạng còn thiếu `ECSGD`↔`ECSHT` ở §7 (đánh dấu 🔴 chờ `inf` thiết kế đường kết nối thật). Rà theo cùng nguyên tắc cho mọi `IF` khác: `IF-022` (Cart&Order ↔ Seller Management, cũng GD↔HT) trước đây không có nhãn loại — nay ghi rõ **cũng cross-network** (không phải "đổi loại", chỉ làm rõ vì trước đó chưa từng gán nhãn "internal"); `IF-005` (trong Nhóm Giao dịch) giữ **in-process** (không đổi, đúng từ trước); `IF-006` (Cart&Order→Payment) giữ **cross-network** (không đổi, đúng từ trước). Không `IF` nào khác đổi loại. (2) Đếm lại `IF-nn`: đối chiếu toàn bộ sơ đồ Context/Container/Component (§3/§4/§5) với bảng `CMP-nn` (§4.1) và bảng phụ thuộc (§6.3) — chỉ **17 ID** thực sự xuất hiện (`IF-001…009, 015…022`), không có `IF-010…014` ở bất kỳ đâu, không có mũi tên nào thiếu ID → **kết luận: con số "22" là đếm nhầm ở bản gốc, không phải bỏ sót interface**. Sửa "22"→"17" ở header (`Approved by`), Change Log v1.0/v1.0-sign, `§Tự chấm` (D5, đoạn Nhắc cuối) — nội dung chuyên môn (17 `IF-nn`, `CMP`, ma trận `ASR×CMP`) không đổi, chỉ sửa số đếm sai. Đóng `OQ-029` trong sổ `00-index/OQ_e-commerce.md` với kết luận trên. `OQ-028` **giữ nguyên mở** (SAD nay đã hết mâu thuẫn nội bộ, vẫn chờ Tech Lead thật xác nhận ranh giới mạng). Không sửa §8 (`ADR` links), không sửa `ASR`/`QAS`/`ADR`/`ICD`. Ghi ngoại lệ tiếp tục gate ở `DEC-20` (`00-index/DEC_e-commerce.md`), tiếp nối `DEC-01…19`. `Confidence` giữ 🔴; Status giữ 🟡 Draft; §4/§6/§7 v1.2 **chưa được Tech Lead/Security/Ops ký lại**. | — |
+| 1.3 | 2026-09-15 | SA (qua skill sa-2-architecture, chế độ `go`, hoạt động `adr`) | **Sửa nhất quán tối thiểu theo `ADR-013` (`Proposed`), yêu cầu người duyệt 2026-09-15** — hiện thực hoá Lựa chọn B đã chọn ở `OQ-034`/`DEC-22` (bất đồng bộ hoá bước khởi tạo thanh toán VNPay/Momo trong `POST /v1/checkout`). **Đây là nội dung kiến trúc mới, không phải sửa lỗi tài liệu như v1.2.** (1) §6.1: sequence diagram checkout chèn nhánh rẽ theo phương thức thanh toán — COD giữ nguyên luồng đồng bộ cũ; VNPay/Momo dừng đường găng đồng bộ ngay sau khi commit TX Order (bước ghi `Order`/`OrderSeller`/`OrderItem`), trả response `201` với `orderId` + `status: PENDING_PAYMENT_INIT` (chưa có `redirectUrl`), việc gọi VNPay/Momo chuyển thành bất đồng bộ qua message `PaymentInitRequested` (tái dùng message backbone `ADR-005`) — Payment Service consume, gọi gateway, publish `PaymentInitReady`/`PaymentInitFailed`; thêm chú thích tham chiếu `ADR-013` ngay dưới sơ đồ và cập nhật bảng bước kèm theo. (2) §8: thêm dòng `ADR-013` vào bảng "Quyết định kiến trúc đã ghi" (Status `Proposed`, radar 7, không bắt buộc POC vì dưới ngưỡng 8, chờ Tech Lead + PO thật xác nhận). Không sửa nội dung khác của `SAD` (C4 §3–§5, `CMP` §4.1, deployment view §7, §9, §10, §11 giữ nguyên như v1.2) — đúng phạm vi được giao. `OQ-034` cập nhật trạng thái "đã có `ADR-013`, chờ Tech Lead/PO thật xác nhận" trong sổ `00-index/OQ_e-commerce.md`. Thêm `OQ-041`, `OQ-042` (mới, từ `ADR-013`). Ghi ngoại lệ tiếp tục gate ở `DEC-23` (`00-index/DEC_e-commerce.md`), tiếp nối `DEC-01…22`. `Confidence` giữ 🔴 — chưa có bằng chứng nguồn mới (chưa đo thật, chưa Tech Lead/PO thật ký); Status giữ 🟡 Draft; §6.1/§8 bản v1.3 **chưa được Tech Lead/Security/Ops ký**. | `ADR-013` |
+
+> Sơ đồ thắng về **quan hệ và luồng** (ai gọi ai, theo thứ tự nào).
+> Bảng/văn bản thắng về **ràng buộc và con số** (timeout, quyền, định dạng, giới hạn).
+> Mâu thuẫn ngoài hai loại trên là lỗi tài liệu, phải sửa chứ không phải chọn bên (`D12`).
+
+---
+
+## 0. Ghi chú Preflight & ngoại lệ gate — bắt buộc đọc trước
+
+**AG1 vẫn chưa được ký chính thức** và **AG2 (gate của chính GĐ2) càng chưa tới hạn** — tài liệu
+này là hoạt động 3/9 của `sa-2-architecture`. Theo đúng thứ tự bắt buộc của `SKILL.md` ("1→2→3
+bắt buộc trước; 4–8 chạy song song được"): hoạt động 1 (`QAS`) và hoạt động 2 (`ASR`) đã hoàn tất
+và được duyệt từng phần (`DEC-12`, `DEC-14`) — điều kiện đầu vào cho `sad` đã đủ.
+
+Người dùng (vai điều phối dự án chạy thử) đã được cảnh báo lại và **khẳng định muốn tiếp tục**
+sang hoạt động 3 (`SAD`). Quyết định ngoại lệ này được ghi tại `DEC-15` dưới đây và tại sổ
+`00-index/DEC_e-commerce.md`.
+
+> **DEC-15 (SA)** — Tiếp tục `sa-2-architecture` (hoạt động 3 — `SAD`) cho e-commerce trong khi
+> AG1 chưa có chữ ký PO/Tech Lead thật và AG2 (gate của chính GĐ2) chưa tới hạn — tiếp nối
+> `DEC-01…14`.
+> **Quyết định:** Dựng `SAD` (C4 Context/Container/Component, deployment view, bảng `CMP-nn`,
+> ma trận `ASR×CMP`) dựa trên hướng kiến trúc P2 đã duyệt từng phần (`DEC-06`/`DEC-14`), giữ
+> `Confidence 🔴` cho tới khi: (a) AG1 ký thật, (b) `ADR-001` (kiểu kiến trúc tổng thể) được viết
+> và `Accepted`, (c) `POC-01`/`POC-02` chạy xong, (d) `OQ-010` (số đội thật, ảnh hưởng ranh giới
+> nhóm triển khai `ASR-014`) được trả lời.
+> **Người quyết:** Điều phối dự án (đại diện PO, dự án chạy thử).
+> **Radar (ước lượng):** ~4 — chi phí đảo ngược thấp (bản vẽ C4 sửa lại khi `ADR-001` đổi hướng
+> không tốn nhiều so với đã code) · bán kính ảnh hưởng: hoạt động `icd`/`dat`/`sec`/`inf`/`fail`
+> kế tiếp phụ thuộc `SAD` này, nhưng bản thân *việc ghi tài liệu dưới ngoại lệ* thì nhỏ · có chạm
+> `QAS`/`ASR` Must trực tiếp (đang hiện thực hoá chúng thành component) nhưng chưa phải cam kết
+> thi công (chưa `ADR` nào `Accepted`) · không ràng buộc dài hạn tự thân (văn bản `SAD` sửa được
+> qua version mới, khác `ADR` bất biến) · không tranh cãi mới, tiếp nối tiền lệ `DEC-11…14` →
+> **ghi `DEC-nn`, không cần `ADR` cho việc chạy dưới ngoại lệ** (`decision-radar.md §1–§2`).
+> **Hệ quả nếu không chấp nhận ngoại lệ:** dừng GĐ2 ở hoạt động `asr`, không có `SAD` để hoạt
+> động `icd`/`dat`/`sec`/`inf`/`fail` (hoạt động 4–8) dùng làm đầu vào — chậm tiến độ chạy thử
+> tương ứng thời gian xử lý các `OQ` đang mở, đặc biệt `OQ-010` (ảnh hưởng trực tiếp §4.1/§7).
+
+**Cập nhật v1.2 (2026-09-15):** Người duyệt yêu cầu sửa lỗi nhất quán phát hiện bởi hoạt động
+`icd` (`OQ-028`/`OQ-029`) — đây là sửa lỗi tài liệu, **không phải** quyết định kiến trúc mới, không
+cần `ADR`. Người dùng (vai điều phối dự án chạy thử) đã được cảnh báo lại AG1/AG2 vẫn chưa qua và
+**khẳng định muốn tiếp tục**. Ghi ngoại lệ tiếp tục tại `DEC-20` (`00-index/DEC_e-commerce.md`),
+tiếp nối `DEC-01…19`.
+
+🔴 **Nhắc quan trọng:** `ADR`, `ICD`, `DAT`, `SEC`, `INF`, `FAIL` **chưa được tạo**. Tài liệu này
+đánh dấu rõ 12 chỗ chờ `ADR-001…012` (§8) và ghi ứng viên `IF-nn` (§4.1, §6.3), thực thể dữ liệu
+sở hữu (§4.1, cho `DAT`), phụ thuộc cần `FAIL` (§6.3) — để các hoạt động kế tiếp không phải dò
+lại từ đầu, **không thay thế** các hoạt động đó.
+
+---
+
+## 1. Tóm tắt cho người quyết định
+
+| | |
+|---|---|
+| **Kiểu kiến trúc** | Modular monolith theo domain, chạy trên AWS managed service (ECS Fargate), **tách riêng duy nhất Payment Service** (mạng/IAM/DB riêng) — phương án **P2** của `OPT`, chưa có `ADR-001` chính thức (vẫn `Proposed`, xem §8) |
+| **Quyết định lớn nhất** | `ADR-001` — Modular Monolith P2 thay vì ~10 microservices (P1, đã loại ở `OPT §5`); radar ước lượng ~7, cần `POC-01`/`POC-02` trước khi `Accepted` |
+| **Rủi ro kiến trúc lớn nhất** | `ARISK-01`/`ARISK-02` (SQS/EventBridge và RDS gộp chưa đo throughput thật) — chặn trực tiếp `ADR-005`/`ADR-006` (radar ≥8, xem `ASR-005`/`ASR-006`) |
+| **Cái này KHÔNG làm được** | Scale-out **độc lập** Catalog/Search khỏi Cart/Checkout ngay từ ngày một (thua P1 đúng 1 bậc ở `OPT §4`); chưa dùng OpenSearch (hoãn, dùng Postgres FTS); chưa tách ranh giới ECS chi tiết theo "Nhóm giao dịch"/"Nhóm hỗ trợ" trong `TCO` (xem `OQ-026`) |
+
+---
+
+## 2. Kiểu kiến trúc và lý do
+
+Quyết định ở `ADR-001` (chưa viết — xem §8). Tóm tắt lý do gắn với `ASR`/`CON`:
+
+| Tín hiệu trong dự án này | Nghiêng về | Kết luận |
+|---|---|---|
+| `CON-05` (số đội thi công chưa xác nhận thật, giả định tạm "team MVP chuẩn" `DEC-02`, hồ sơ thầu BE trung bình ~2,6 FTE/tháng) so với ~10 service độc lập của P1 | Modular monolith — mỗi BE ôm 3–4 service ở P1 vi phạm Conway rõ (`OPT §4` tiêu chí 5: P1=2, P2=5) | Giữ P2 — 2–3 nhóm triển khai thay vì ~10 |
+| `ASR-001`/`ASR-014` (tải lệch Catalog/Cart&Order so với nhóm hỗ trợ, cần scale nhanh hơn) | Tách logic thành ≥2 nhóm triển khai trong cùng monolith thay vì 1 khối duy nhất | 2 nhóm container logic: "Nhóm Giao dịch" và "Nhóm Hỗ trợ" (§4.1) + Payment tách biệt |
+| `CON-05`/`OQ-010` (chưa xác nhận đội thi công thật từng vận hành Kafka/MSK/OpenSearch/EKS production) | Managed service đơn giản hơn (SQS/EventBridge, ECS Fargate, RDS) thay vì tự vận hành cluster | Loại Kafka/MSK/OpenSearch cho MVP — dùng SQS FIFO + EventBridge (`ASR-005`) và Postgres FTS giai đoạn đầu |
+| `CON-06` (PCI-DSS SAQ A, không thương lượng) | Payment phải là ranh giới mạng/IAM/DB riêng bất kể chọn monolith hay microservices | Payment Service tách hoàn toàn (`ASR-002`) — quyết định này **không phụ thuộc** việc chọn P1 hay P2 |
+
+🔴 **Modular monolith là mặc định hợp lý** cho ≤2 team và ranh giới nghiệp vụ chưa ổn định — ở
+đây team thi công thật **chưa được Tech Lead xác nhận** (`OQ-010` còn mở); ranh giới 2 nhóm logic
+dưới đây (`ASR-014`) dựa trên giả định team `DEC-02`, phải rà lại khi có số thật.
+
+---
+
+## 3. C4 — Mức 1: System Context
+
+*Mức: **C4 Context**. Ai dùng hệ thống, hệ thống nói chuyện với cái gì bên ngoài. Không có chi
+tiết bên trong.*
+
+```mermaid
+flowchart LR
+    Guest(["○ Guest\n(chưa đăng nhập)"])
+    Customer(["○ Customer"])
+    Seller(["○ Seller"])
+    Admin(["○ Admin\n(bắt buộc MFA — ASR-009)"])
+
+    subgraph SYS["▭ Sàn e-commerce — P2: Modular Monolith + managed AWS, Payment tách riêng"]
+        PLATFORM["Nền tảng e-commerce\n(Identity · Catalog · Cart&Order · Seller · Commission ·\nPromotion&Loyalty · Review · Notification · Shipping · Payment)"]
+    end
+
+    VNPay["▱ VNPay\n(cổng thanh toán)"]
+    Momo["▱ Momo\n(cổng thanh toán)"]
+    GHN["▱ GHN\n(vận chuyển)"]
+    GHTK["▱ GHTK\n(vận chuyển, fallback GHN)"]
+    EmailSMS["▱ Email/SMS Provider\n(nhà cung cấp chưa chốt — CTX §4.2)"]
+
+    Guest -->|"1 · HTTPS REST, sync"| PLATFORM
+    Customer -->|"1 · HTTPS REST, sync"| PLATFORM
+    Seller -->|"1 · HTTPS REST, sync"| PLATFORM
+    Admin -->|"1 · HTTPS REST, sync"| PLATFORM
+
+    PLATFORM -->|"2 · REST (init) sync + Webhook IPN async"| VNPay
+    PLATFORM -->|"2 · REST (init) sync + Webhook IPN async"| Momo
+    PLATFORM -->|"3 · REST (tạo/tra vận đơn) sync + Webhook async"| GHN
+    PLATFORM -->|"3 · REST sync + Webhook async, fallback GHN"| GHTK
+    PLATFORM -->|"4 · REST/SDK qua queue, async"| EmailSMS
+```
+
+**Legend:** ▭ hệ thống của ta · ▱ hệ thống ngoài · ○ người dùng · ──▶ nhãn số + giao thức + sync/async ghi trên mũi tên.
+
+| Thực thể ngoài | Vai trò | Ai sở hữu | Giao thức | SLA của họ | `IF-nnn` ứng viên |
+|---|---|---|---|---|---|
+| VNPay | Cổng thanh toán online (redirect + IPN), không lưu thẻ | VNPay (bên thứ ba) | REST/HTTPS, timeout đề xuất 10s (kế thừa `CTX §4.2`, **chưa kiểm chứng sandbox thật**) | 🔴 Chưa xác nhận (`CON-04`) | `IF-007` |
+| Momo | Tương tự VNPay | Momo (bên thứ ba) | REST/HTTPS, timeout đề xuất 10s | 🔴 Chưa xác nhận (`CON-04`) | `IF-008` |
+| GHN | Tạo vận đơn, tra cứu trạng thái, webhook | GHN (bên thứ ba) | REST/HTTPS, timeout đề xuất 8s | 🔴 Chưa xác nhận (`CON-04`) | `IF-018` |
+| GHTK | Tương tự GHN, fallback chéo khi GHN lỗi (`ASR-013`) | GHTK (bên thứ ba) | REST/HTTPS, timeout đề xuất 8s | 🔴 Chưa xác nhận (`CON-04`) | `IF-019` |
+| Email/SMS Provider | Thông báo đơn hàng/giao hàng, đa ngôn ngữ | Chưa chọn (`SAD.md §3.4` tự ghi "chưa chốt"; 🔴🔴 mức chưa sẵn sàng cao nhất theo `CTX §4.2`) | REST/HTTPS hoặc SDK qua queue, timeout đề xuất 5s | Chưa có nhà cung cấp | `IF-020` |
+
+*Ngoài phạm vi Context này (đã ghi ở `CTX §4.2`, không lặp lại chi tiết): Google/Facebook OAuth
+(Should, `DRV` không có — không chặn MVU vì email/password vẫn hoạt động độc lập); ngân hàng
+payout (COD/hoa hồng, luồng nội bộ tài chính, không phải điểm tích hợp giao dịch của Cart &
+Checkout). Không vẽ vào Context vì không thuộc phạm vi bắt buộc của ghi chú người duyệt.*
+
+---
+
+## 4. C4 — Mức 2: Container
+
+*Mức: **C4 Container**. Các khối chạy được và triển khai được. Đây là sơ đồ dev dùng nhiều nhất.*
+
+```mermaid
+flowchart TB
+    WebApp["Web/Mobile Client\n(Guest/Customer/Seller/Admin)"]
+
+    ALB["ALB / API Gateway\n(WAF gắn kèm — TCO §3.2)"]
+
+    subgraph MONO["Modular Monolith — ECS Fargate (P2)"]
+        GD["Nhóm Giao dịch\n(Identity&Access · Catalog&Inventory ·\nCart&Order + Dispute)"]
+        HT["Nhóm Hỗ trợ\n(Seller Mgmt · Commission&Payout ·\nPromotion&Loyalty · Review · Notification ·\nShipping&Fulfillment)"]
+    end
+
+    PAY["Payment Service\n(mạng/IAM riêng — ASR-002)"]
+
+    BUS[("SQS FIFO (group=seller_id)\n+ EventBridge — ASR-005")]
+    RDS[("RDS PostgreSQL Multi-AZ chính\nschema-per-module — ASR-006")]
+    RDSPAY[("RDS PostgreSQL riêng\nchỉ Payment — ASR-002")]
+    REDIS[("ElastiCache Redis\ncache/session/ownership")]
+    S3CF[("S3 + CloudFront\nasset/ảnh sản phẩm/KYC")]
+
+    VNPay["VNPay"]
+    Momo["Momo"]
+    GHN["GHN"]
+    GHTK["GHTK"]
+    EmailSMS["Email/SMS Provider"]
+
+    WebApp -->|"1 · HTTPS REST, sync"| ALB
+    ALB -->|"2 · REST, sync"| GD
+    ALB -->|"3 · REST, sync"| HT
+    ALB -->|"4 · REST, sync, cô lập mạng"| PAY
+    GD -->|"5 · SQL, sync"| RDS
+    HT -->|"5 · SQL, sync"| RDS
+    PAY -->|"6 · SQL, sync"| RDSPAY
+    GD -->|"7 · cache/session, sync"| REDIS
+    GD -->|"8 · publish OrderPlaced, async"| BUS
+    PAY -->|"8b · publish PaymentConfirmed, async"| BUS
+    BUS -->|"9 · consume, async"| HT
+    GD -->|"10 · asset, sync"| S3CF
+    GD -->|"11 · REST, sync — áp dụng coupon/điểm (OQ mới BA §OQ-017)"| HT
+    PAY -->|"12 · REST sync (init) + webhook async"| VNPay
+    PAY -->|"12 · REST sync (init) + webhook async"| Momo
+    HT -->|"13 · REST sync + webhook async"| GHN
+    HT -->|"13 · REST sync + webhook async, fallback"| GHTK
+    HT -->|"14 · SDK/queue, async"| EmailSMS
+```
+
+**Legend:** ▭ container ta sở hữu · hình trụ = data store · nhãn số + giao thức + sync/async
+bắt buộc trên mọi mũi tên (`D4`) · mũi tên "11" (Cart&Order → Promotion&Loyalty, `IF-021`) **là
+cross-network REST** — Nhóm Giao dịch và Nhóm Hỗ trợ là **2 ECS Fargate service riêng** (theo
+`OQ-026`/`ASM-23` đã chốt TẠM), không phải cùng process.
+
+🔴 **Sửa v1.2:** bản trước (v1.0/v1.1) ghi nhầm mũi tên "11" là "internal call trong cùng
+process/network boundary" — mâu thuẫn trực tiếp với `OQ-026` (2 nhóm ECS riêng) đã chốt TẠM ngay
+trong cùng tài liệu. Phát hiện bởi `ICD §0`/`OQ-028` (`ASM-24`). Timeout/fallback cụ thể **chưa
+chốt** — ứng viên `FAIL` có mức ưu tiên cao hơn vì nay là cross-network call nằm trong đường găng
+checkout (ngân sách `QAS-002` ≤3s). Không mũi tên container↔container nào còn được coi là
+"internal" trong sơ đồ này — kể cả `IF-022` (Cart&Order↔Seller Management, cũng Nhóm Giao
+dịch↔Nhóm Hỗ trợ, xem footnote §4.1).
+
+### 4.1 Bảng container/component — `CMP-nn`
+
+*Cột "Nhóm triển khai" theo yêu cầu người duyệt: **Nhóm giao dịch** / **Nhóm hỗ trợ** / **Payment
+(tách biệt)** / **Hạ tầng dùng chung** (không thuộc 3 nhóm compute, dùng chung bởi nhiều nhóm) —
+theo `ASR-014`.*
+
+| ID | Tên | Trách nhiệm *(một câu)* | **Cái nó KHÔNG làm** | Dữ liệu sở hữu *(ứng viên `DAT`)* | Interface vào | Interface ra | Team | `ASR` ép ra | Nhóm triển khai |
+|---|---|---|---|---|---|---|---|---|---|
+| `CMP-01` | ALB / API Gateway | Định tuyến, TLS termination, WAF, biên rate-limit ngoài | Không chứa business logic; không tự quyết định authz chi tiết (chỉ chuyển token/session xuống) | Không (stateless) | `IF-001` | `IF-002`, `IF-003`, `IF-004` | Platform/DevOps | `ASR-007` (một phần — chỗ ra quyết định authz) | Hạ tầng dùng chung |
+| `CMP-02` | Identity & Access | Đăng ký/đăng nhập, phát hành JWT/session, MFA Admin (`ASR-009`) | Không quyết định ownership dữ liệu Cart/Order (chỉ cấp danh tính) | `User`/`Account`, `Session`, `MFA config` | `IF-002` | `IF-015` (Redis) | BE (nhóm giao dịch) | `ASR-007`, `ASR-009`, `ASR-010`, `ASR-011` | Nhóm Giao dịch *(`ASM-22` mới — xem §10)* |
+| `CMP-03` | Catalog & Inventory | Quản lý Product/Variant/Category, tồn kho, giữ tồn kho (reserve) lúc checkout | Không tính giá cuối cùng có khuyến mãi (phối hợp với Promotion&Loyalty) | `Product`, `ProductVariant`, `Category`, `InventoryStock` | `IF-002`, `IF-005` | `IF-016` (RDS) | BE (nhóm giao dịch) | `ASR-006`, `ASR-015` | Nhóm Giao dịch |
+| `CMP-04` | Cart & Order (+ Dispute) | Giỏ hàng đa seller, checkout, tách `Order`/`OrderSeller` theo seller (`ASR-003`), ownership check | Không xử lý thanh toán thật (chuyển Payment Service); không tính hoa hồng | `Cart`, `CartItem`, `Order`, `OrderSeller`, `OrderItem`, `Dispute` | `IF-002` | `IF-005`, `IF-006`, `IF-009`, `IF-021`, `IF-022` | BE (nhóm giao dịch, chi tiết nhất — §5) | `ASR-001`, `ASR-003`, `ASR-004` (phần cập nhật status), `ASR-007`, `ASR-008`, `ASR-010`, `ASR-011` | Nhóm Giao dịch |
+| `CMP-05` | Seller Management | Onboarding/KYC seller, quản trị seller (khoá/duyệt) | Không tính hoa hồng/payout | `Seller`, `KYC document` (S3 ref) | `IF-003` | `IF-016`, `IF-022` | BE (nhóm hỗ trợ) | `ASR-008` | Nhóm Hỗ trợ |
+| `CMP-06` | Commission & Payout | Cấu hình hoa hồng theo ngành hàng, tính hoa hồng, lịch payout, kỳ giữ tiền (hold) | Không khởi tạo giao dịch thanh toán khách hàng | `CommissionConfig`, `PayoutBatch`, `PayoutLedger` | `IF-009` | *(ngân hàng payout — ngoài phạm vi module này)* | BE (nhóm hỗ trợ) | `ASR-003` (tiêu thụ `OrderSeller`), `ASR-005` | Nhóm Hỗ trợ |
+| `CMP-07` | Promotion & Loyalty | Cấu hình coupon, tích/đổi điểm, xếp hạng thành viên; API áp dụng mã/điểm cho checkout | Không tạo `Order` | `Coupon`/`Promotion`, `LoyaltyPoint`, `MembershipTier` | `IF-009`, `IF-021` | — | BE (nhóm hỗ trợ) | `ASR-005` (consumer fan-out) | Nhóm Hỗ trợ |
+| `CMP-08` | Review | Đánh giá/nhận xét sản phẩm sau khi mua | Không xử lý đơn hàng | `Review`, `Rating` | `IF-003`, `IF-009` | — | BE (nhóm hỗ trợ) | `ASR-005` (consumer fan-out) | Nhóm Hỗ trợ |
+| `CMP-09` | Notification | Gửi email/SMS theo sự kiện, nội dung đa ngôn ngữ cho UI hệ thống (`ASR-015`) | Không tự quyết định nội dung nghiệp vụ (chỉ render template theo sự kiện) | `NotificationLog`, `Template` | `IF-009` | `IF-020` | BE (nhóm hỗ trợ) | `ASR-005`, `ASR-015` | Nhóm Hỗ trợ |
+| `CMP-10` | Shipping & Fulfillment | Điều phối đóng gói, tích hợp GHN/GHTK, cập nhật trạng thái giao hàng, fallback chéo (`ASR-013`) | Không tính phí hoa hồng | `ShippingOrder`/`Waybill`, tracking status | `IF-003`, `IF-009` | `IF-018`, `IF-019` | BE (nhóm hỗ trợ) | `ASR-013` | Nhóm Hỗ trợ |
+| `CMP-11` | Payment Service | Khởi tạo giao dịch VNPay/Momo, xử lý webhook idempotent (`ASR-004`), xử lý trạng thái COD, đối soát bù, **không lưu thẻ** | Không giữ dữ liệu Cart/Order (chỉ nhận/trả `gateway_transaction_ref` + status) | `Payment`, `PaymentTransaction`, `ReconciliationLog` | `IF-004`, `IF-006`, `IF-007` (webhook), `IF-008` (webhook) | `IF-007`, `IF-008`, `IF-009`, `IF-017` | BE riêng (Payment, cô lập) | `ASR-002`, `ASR-004`, `ASR-010`, `ASR-011`, `ASR-013` | **Payment (tách biệt)** |
+| `CMP-12` | Message Backbone (SQS FIFO + EventBridge) | Truyền sự kiện `OrderPlaced`/`PaymentConfirmed` bất đồng bộ, đảm bảo thứ tự theo `seller_id` | Không lưu trạng thái nghiệp vụ lâu dài (chỉ transit + DLQ tạm) | Không (message transit) | `IF-009` (publish) | `IF-009` (consume bởi HT) | Platform/SRE | `ASR-005` | Hạ tầng dùng chung *(publish: Nhóm Giao dịch + Payment; consume: Nhóm Hỗ trợ)* |
+| `CMP-13` | RDS chính (schema-per-module) | Lưu trữ giao dịch cho mọi module trừ Payment, chịu tải ghi/đọc gộp | Không lưu dữ liệu Payment (RDS riêng) | Schema của `Identity`/`Catalog`/`Cart&Order`/`Seller`/`Commission`/`Promotion`/`Review`/`Notification`/`Shipping` | `IF-016` | — | Ops/DBA | `ASR-006` | Hạ tầng dùng chung *(Nhóm Giao dịch + Nhóm Hỗ trợ)* |
+| `CMP-14` | RDS Payment (riêng) | Lưu trữ `Payment`/`PaymentTransaction`, tách biệt hoàn toàn | Không cho module khác truy cập trực tiếp | `Payment`, `PaymentTransaction` | `IF-017` | — | Ops/DBA | `ASR-002`, `ASR-006` | Payment (tách biệt) |
+| `CMP-15` | ElastiCache Redis | Cache session/ownership/giỏ hàng để đạt ngân sách latency (`QAS-003`/`004`) mà không tra DB mỗi request | Không là nguồn sự thật (source of truth) — chỉ cache | Không (cache, TTL) | `IF-015` | — | Ops/SRE | `ASR-007` | Nhóm Giao dịch *(chủ yếu)* |
+
+🔴 **15/15 `CMP` có ít nhất một `ASR` phục vụ — không có `CMP` mồ côi.** `ASR-001` (kiểu kiến
+trúc tổng thể), `ASR-012` (AWS bắt buộc) và `ASR-014` (ranh giới nhóm triển khai) là ràng buộc
+**cấu trúc/nền** áp dụng cho toàn bộ bảng trên (không map vào một `CMP` đơn lẻ) — xem ma trận
+đầy đủ ở §4.3.
+
+🔴 **Bổ sung v1.2 (rà theo `OQ-028`):** cột "Interface ra/vào" ở trên chỉ ghi ID, không ghi loại
+kết nối — để tránh mơ hồ, ghi rõ tại đây: `IF-021` (`CMP-04`→`CMP-07`) và `IF-022` (`CMP-04`↔
+`CMP-05`) đều là **cross-network REST** (Nhóm Giao dịch ↔ Nhóm Hỗ trợ, 2 ECS Fargate service
+riêng theo `OQ-026`/`ASM-23`) — không phải in-process. `IF-005` (`CMP-04`→`CMP-03`, cùng Nhóm
+Giao dịch) vẫn **in-process** (không đổi). `IF-006` (`CMP-04`→`CMP-11`) vẫn **cross-network**
+(Payment luôn tách biệt, không đổi). Không `IF` nào khác đổi loại trong lượt sửa này.
+
+### 4.2 Ranh giới thay đổi
+
+| Loại thay đổi hay xảy ra | Chạm những container nào | Có chấp nhận được không |
+|---|---|---|
+| Thêm kênh thanh toán mới (VD ví điện tử khác) | `CMP-11` Payment Service + `CMP-14` RDS Payment | ✅ Chấp nhận — đúng ranh giới cô lập `ASR-002`, không chạm Nhóm Giao dịch/Hỗ trợ |
+| Đổi quy tắc tính hoa hồng theo ngành hàng | `CMP-06` Commission & Payout | ✅ Chấp nhận — chỉ chạm Nhóm Hỗ trợ |
+| Thêm ngôn ngữ hiển thị mới (UI hệ thống) | `CMP-09` Notification, `CMP-03` Catalog (nội dung sản phẩm nếu PO đổi phạm vi `OQ-025`), tầng FE (ngoài `SAD`) | ✅ Chấp nhận một phần — xem `ASR-015`, `OQ-025` (vẫn mở) |
+| Đổi phí ship theo seller (VD trợ giá) | `CMP-04` Cart & Order (Nhóm Giao dịch) + `CMP-10` Shipping & Fulfillment (Nhóm Hỗ trợ) | ✅ Chạm 2 container nhưng chấp nhận được — đây là bản chất của luồng tách đơn theo seller (`ASR-003`), không phải dấu hiệu cắt sai |
+| Đổi mô hình tách đơn (VD gộp nhiều seller vào 1 đơn) | `CMP-04`, `CMP-06`, `CMP-08`, `CMP-10` (≥4 container) | ⚠️ **Không nên xảy ra thường xuyên** — đây là core domain model (`ASR-003`/`ADR-003`, radar ~6); nếu phát sinh nhu cầu đổi, đó là tín hiệu cần rà lại `ADR-003`, không phải lỗi phân rã |
+
+Không có loại thay đổi thường xuyên nào chạm ≥3 container ngoài trường hợp core model đã ghi
+chú ở trên (đúng kỳ vọng của mục này — phân rã đang cắt theo domain, không theo tầng kỹ thuật).
+
+### 4.3 Ma trận `ASR` × `CMP` *(đủ 15/15)*
+
+| `ASR` | `CMP` phục vụ | Ghi chú |
+|---|---|---|
+| `ASR-001` | *Toàn bộ cấu trúc container ở §4* (ranh giới 3 nhóm triển khai + Payment tách riêng) | Không map vào một `CMP` đơn lẻ — là quyết định cấu trúc tổng thể, xem `ADR-001` |
+| `ASR-002` | `CMP-11`, `CMP-14` | Payment Service + RDS riêng |
+| `ASR-003` | `CMP-04`, `CMP-06` (tiêu thụ), `CMP-10` (tiêu thụ) | Mô hình `Order`/`OrderSeller` do `CMP-04` sở hữu |
+| `ASR-004` | `CMP-11` (webhook + đối soát), `CMP-04` (cập nhật `OrderSeller.status`) | |
+| `ASR-005` | `CMP-12`, `CMP-06`, `CMP-07`, `CMP-08`, `CMP-09`, `CMP-10` | Message backbone + 5 consumer fan-out (khớp `ASR-005` "≥5 consumer") |
+| `ASR-006` | `CMP-13`, `CMP-14` | |
+| `ASR-007` | `CMP-01`, `CMP-02`, `CMP-04`, `CMP-15` | Chỗ ra quyết định authz + cache — chi tiết ở hoạt động `sec` |
+| `ASR-008` | `CMP-04` (tách đơn seller data), `CMP-05` (KYC PII) | |
+| `ASR-009` | `CMP-02` | |
+| `ASR-010` | `CMP-02`, `CMP-04`, `CMP-11` | Nhóm "giao dịch cốt lõi" cho HA/DR — khớp đúng 3 `CMP` này |
+| `ASR-011` | `CMP-02`, `CMP-04`, `CMP-11` | Cùng 3 `CMP` như `ASR-010` (observability cho cùng nhóm cốt lõi) |
+| `ASR-012` | *Ràng buộc nền cho mọi `CMP`* | Mọi dịch vụ managed dùng ở §4/§7 đều là AWS — không sinh `CMP` riêng |
+| `ASR-013` | `CMP-11` (VNPay/Momo), `CMP-10` (GHN/GHTK) | |
+| `ASR-014` | *Cột "Nhóm triển khai" của toàn bộ bảng §4.1* | Xem `ADR-012`; phụ thuộc `OQ-010` (số đội thật) |
+| `ASR-015` | `CMP-03` (nội dung sản phẩm), `CMP-09` (thông báo) | Phần lớn thuộc tầng FE, ngoài phạm vi `SAD` backend |
+
+---
+
+## 5. C4 — Mức 3: Component *(container phức tạp nhất — Nhóm Giao dịch, chi tiết Cart & Order)*
+
+*Mức: **C4 Component**. Theo yêu cầu người duyệt "chi tiết nhất cho Giỏ hàng & Checkout" — vẽ
+mức Component cho container "Nhóm Giao dịch", xoáy vào `CMP-04` Cart & Order vì đây là logic
+phức tạp nhất (tách đơn theo seller, ownership check, phối hợp Catalog/Payment/Promotion).*
+
+```mermaid
+flowchart TB
+    subgraph GD["Nhóm Giao dịch — Component view"]
+        API["Cart/Checkout API\n(GET/PATCH/DELETE /v1/cart*, POST /v1/checkout)"]
+        OWN["Ownership Check\n(ASR-007)"]
+        CARTSVC["Cart Service\n(CartItem, nhóm theo seller_id)"]
+        CHECKOUT["Checkout Orchestrator\n(tách Order/OrderSeller — ASR-003)"]
+        IDSVC["Identity & Access\n(CMP-02)"]
+        CATSVC["Catalog & Inventory\n(CMP-03)"]
+    end
+
+    REDIS[("Redis — session/ownership cache")]
+    RDS[("RDS chính")]
+    PAY["Payment Service\n(ranh giới mạng khác — CMP-11)"]
+    BUS[("SQS FIFO/EventBridge")]
+    PROMO["Promotion & Loyalty\n(Nhóm Hỗ trợ, CMP-07)"]
+
+    API --> OWN
+    OWN -->|"15 · cache hit, sync"| REDIS
+    OWN -->|"nếu cache miss, sync"| IDSVC
+    API --> CARTSVC
+    CARTSVC -->|"16 · SQL, sync"| RDS
+    CARTSVC -->|"5 · kiểm tra/giữ tồn kho, sync"| CATSVC
+    API --> CHECKOUT
+    CHECKOUT -->|"16 · SQL, sync (ghi Order/OrderSeller/OrderItem)"| RDS
+    CHECKOUT -->|"21 · REST, sync — áp dụng coupon/điểm"| PROMO
+    CHECKOUT -->|"6 · REST, sync — khởi tạo thanh toán"| PAY
+    CHECKOUT -->|"9 · publish OrderPlaced, async"| BUS
+```
+
+**Legend:** số trên mũi tên tham chiếu đúng `IF-nnn` ứng viên ở §4.1/§6.3 (không tạo số mới ở
+mức Component — dùng lại `IF-005`, `IF-006`, `IF-009`, `IF-015`, `IF-016`, `IF-021`).
+
+🔴 **Sửa v1.2:** mũi tên "21" (`CHECKOUT`→`PROMO`, `IF-021`) là **cross-network REST** — `PROMO`
+thuộc Nhóm Hỗ trợ, đã vẽ ngoài subgraph `GD` từ trước (đúng), chỉ chú thích lại cho khớp legend §4
+đã sửa; không đổi hình vẽ.
+
+---
+
+## 6. Luồng chính
+
+*Sequence diagram cho 2 luồng quan trọng nhất của Giỏ hàng & Checkout, theo `PROCESS_CartCheckout_v1.0.md` B1–B9.*
+
+### 6.1 Checkout (tạo Order/OrderSeller đồng bộ; khởi tạo thanh toán online bất đồng bộ — `ADR-013`)
+
+🔴 **Sửa v1.3 (`ADR-013`, `Proposed`):** nhánh VNPay/Momo trước đây gọi Payment Service **đồng bộ**
+trong cùng transaction (v1.0–v1.2) — `FAIL §1.2` phát hiện luồng đó vượt ngân sách `QAS-002`
+(3.220ms > 3.000ms). Từ v1.3, TX **commit ngay sau khi tạo `Order`/`OrderSeller`/`OrderItem`**
+(không giữ mở chờ Payment nữa); COD vẫn xác nhận đồng bộ ngay sau đó (không đổi, không gọi ra
+ngoài); VNPay/Momo chuyển thành **bất đồng bộ** — response trả về ngay với
+`status: PENDING_PAYMENT_INIT`, Payment Service gọi gateway sau, qua message
+`PaymentInitRequested`. Xem mô tả đầy đủ state machine, timeout, idempotency ở
+`adr/ADR-013_bat-dong-bo-hoa-khoi-tao-thanh-toan.md §3`. **Chưa được Tech Lead/PO thật ký** —
+`ADR-013` đang `Proposed`.
+
+```mermaid
+sequenceDiagram
+    participant C as Customer/Guest
+    participant GW as ALB/Gateway
+    participant CO as Cart & Order (CMP-04)
+    participant CAT as Catalog&Inventory (CMP-03)
+    participant PROMO as Promotion&Loyalty (CMP-07)
+    participant PAY as Payment Service (CMP-11)
+    participant DB as RDS chính
+    participant BUS as SQS FIFO/EventBridge
+
+    C->>GW: POST /v1/checkout (Idempotency-Key)
+    GW->>CO: forward request
+    CO->>CAT: kiểm tra + giữ tồn kho (reserve)
+    CAT-->>CO: OK / không đủ (409 ERR_CONFLICT)
+    alt Không đủ tồn kho
+        CO-->>C: 409 — yêu cầu điều chỉnh giỏ (B4)
+    else Đủ tồn kho
+        CO->>PROMO: áp dụng coupon/điểm (nếu có)
+        PROMO-->>CO: giá trị giảm đã tính
+        CO->>DB: BEGIN TX — tạo Order (cha) + N OrderSeller + OrderItem (B5)
+        DB-->>CO: OK
+        CO->>DB: COMMIT TX *(sửa v1.3 — commit ngay, không chờ Payment)*
+        alt COD
+            CO->>PAY: xác nhận COD, sync (Idempotency-Key)
+            PAY-->>CO: xác nhận COD (B7)
+            CO->>BUS: publish OrderPlaced (message group = seller_id)
+            CO-->>C: 201 Created — status CONFIRMED (COD)
+        else VNPay/Momo — bất đồng bộ (ADR-013)
+            CO->>BUS: publish OrderPlaced + PaymentInitRequested (message group = seller_id, Idempotency-Key)
+            CO-->>C: 201 Created — status PENDING_PAYMENT_INIT (chưa có redirectUrl)
+            BUS->>PAY: consume PaymentInitRequested
+            PAY->>PAY: gọi VNPay/Momo (timeout 10s kế thừa CTX §4.2, không còn bị ép ngắn)
+            alt Init thành công
+                PAY->>BUS: publish PaymentInitReady (redirectUrl)
+                Note over C,PAY: FE lấy redirectUrl qua polling/kênh đẩy — cơ chế cụ thể chưa chốt, OQ-041
+            else Init thất bại/timeout
+                PAY->>BUS: publish PaymentInitFailed
+                Note over C,PAY: FE cho khách chọn lại phương thức hoặc chuyển COD — ADR-013 §3.3
+            end
+        end
+    end
+```
+
+| Bước | Thành phần | Đồng bộ? | Timeout *(đề xuất, chi tiết `FAIL §1.2`/`ADR-013 §3.1`)* | Lỗi thì sao | `QAS` liên quan |
+|---|---|---|---|---|---|
+| Kiểm tra/giữ tồn kho | Cart&Order → Catalog | Sync (trong Nhóm Giao dịch) | 150ms | 409, yêu cầu điều chỉnh giỏ (B4) | `QAS-002` |
+| Áp dụng coupon/điểm | Cart&Order → Promotion&Loyalty | **Sync, cross-network** (2 ECS service riêng — `OQ-028`/`ASM-24`) | 400ms | Chưa chốt hành vi lỗi — phụ thuộc `OQ-017` (BA) | `QAS-002` |
+| Tạo Order/OrderSeller + COMMIT | Cart&Order → RDS chính | Sync, 1 transaction, **commit ngay sau bước này** *(sửa v1.3 — không còn giữ TX mở chờ Payment, giảm rủi ro đã nêu ở `FAIL OQ-037/038`)* | 300ms | Rollback toàn bộ TX | `QAS-002`, `QAS-006` |
+| Xác nhận COD *(nhánh COD, không đổi)* | Cart&Order → Payment Service | Sync (vượt ranh giới mạng), nội bộ không gọi gateway ngoài | 600ms | Lỗi → rollback nghiệp vụ (COD không cần gateway ngoài nên hiếm khi lỗi kỹ thuật) | `QAS-002` |
+| **Khởi tạo thanh toán VNPay/Momo *(nhánh online — sửa v1.3, `ADR-013`)*** | Payment Service → VNPay/Momo, **bất đồng bộ sau khi đã trả response** | Async — không tính vào `QAS-002` nữa; timeout tới gateway = 10s kế thừa `CTX §4.2` (không cần ép 1.500ms như đề xuất tạm ở `FAIL v1.0`) | Timeout/lỗi → `PAYMENT_INIT_FAILED`, khách chọn thử lại hoặc chuyển COD (`ADR-013 §3.3`) | `QAS-002` *(nay đạt về cấu trúc, không phụ thuộc SLA đối tác — `CON-04`/`ARISK-03`)* |
+| Publish OrderPlaced (+ PaymentInitRequested cho nhánh online) | Cart&Order → SQS FIFO | Async | N/A (fire-and-forget có retry của SQS) | Message vào DLQ nếu consumer lỗi lặp lại — ứng viên `fail` | `QAS-005` |
+
+### 6.2 Xác nhận thanh toán qua webhook + đối soát bù (bất đồng bộ)
+
+```mermaid
+sequenceDiagram
+    participant GW3 as VNPay/Momo
+    participant PAY as Payment Service (CMP-11)
+    participant DB as RDS Payment
+    participant BUS as SQS FIFO/EventBridge
+    participant CO as Cart & Order (CMP-04)
+    participant RECON as Job đối soát (scheduled)
+
+    GW3->>PAY: Webhook IPN (gateway_transaction_ref, signature)
+    PAY->>PAY: Kiểm tra chữ ký + idempotency (ASR-004)
+    PAY->>DB: Cập nhật Payment.status = success (nếu hợp lệ)
+    PAY->>BUS: publish PaymentConfirmed (message group = seller_id)
+    BUS->>CO: consume — cập nhật OrderSeller.status = confirmed
+
+    loop Mỗi ≤15 phút (đề xuất — QAS-014, chờ OQ-021)
+        RECON->>GW3: Tra cứu trạng thái giao dịch (API đối soát)
+        RECON->>DB: So khớp Payment.status thật vs ghi nhận
+        alt Lệch phát hiện
+            RECON->>RECON: Ghi ReconciliationLog + cảnh báo (QAS-013)
+        end
+    end
+```
+
+| Bước | Thành phần | Đồng bộ? | Timeout *(đề xuất, chờ `fail`)* | Lỗi thì sao | `QAS` liên quan |
+|---|---|---|---|---|---|
+| Nhận webhook | VNPay/Momo → Payment Service | Async (webhook) | N/A (bên gọi retry theo chính sách của họ) | Idempotency key theo `gateway_transaction_ref` — gọi lại không tạo hiệu ứng phụ (`ASR-004`) | `QAS-010`, A4 |
+| Publish PaymentConfirmed | Payment Service → SQS FIFO | Async | N/A | DLQ nếu lỗi lặp lại — ứng viên `fail` | `QAS-005` |
+| Job đối soát bù | Payment Service → VNPay/Momo (polling) | Sync (trong job) | Chưa chốt — ứng viên `fail` | Ghi log + cảnh báo nếu lệch, **không tự động sửa** (cần CSKH/Ops can thiệp theo `IMPACT §1.5`/`PROCESS` B9) | `QAS-014`, `QAS-013` |
+
+### 6.3 Danh sách phụ thuộc vượt ranh giới process — ứng viên cho hoạt động `FAIL`
+
+*Theo `D6` — mọi phụ thuộc dưới đây phải trả lời 4 câu hỏi (chậm/hỏng/sai dữ liệu/hồi phục) ở
+hoạt động `fail` (hoạt động 8, chưa chạy). Liệt kê ở đây để không phải dò lại từ đầu.*
+
+| # | Phụ thuộc | Loại | Timeout đề xuất *(kế thừa, chưa kiểm chứng)* | `IF-nnn` |
+|---|---|---|---|---|
+| 1 | Cart&Order → Catalog&Inventory (kiểm tra/giữ tồn kho) | Internal call (cùng monolith) | Chưa chốt | `IF-005` |
+| 2 | Cart&Order → Promotion&Loyalty (áp dụng coupon/điểm) | **Cross-network REST** (2 ECS service riêng — sửa v1.2 từ "Internal call", xem `OQ-028`/`ASM-24`) | Chưa chốt — ưu tiên cao hơn cho `FAIL` (round-trip mạng thêm vào ngân sách `QAS-002`); hành vi lỗi phụ thuộc `IMPACT §1.5` OQ-017 (BA) | `IF-021` |
+| 3 | Cart&Order → Payment Service | Cross-network REST | Chưa chốt | `IF-006` |
+| 4 | Payment Service → VNPay | External REST + Webhook | 10s (đề xuất, `CTX §4.2`) | `IF-007` |
+| 5 | Payment Service → Momo | External REST + Webhook | 10s (đề xuất) | `IF-008` |
+| 6 | Shipping&Fulfillment → GHN | External REST + Webhook | 8s (đề xuất) | `IF-018` |
+| 7 | Shipping&Fulfillment → GHTK (fallback GHN) | External REST + Webhook | 8s (đề xuất) | `IF-019` |
+| 8 | Notification → Email/SMS Provider | External SDK/queue | 5s (đề xuất) | `IF-020` |
+| 9 | Nhóm Giao dịch/Nhóm Hỗ trợ → RDS chính | DB (SQL) | Chưa chốt | `IF-016` |
+| 10 | Payment Service → RDS Payment | DB (SQL) | Chưa chốt | `IF-017` |
+| 11 | Nhóm Giao dịch → ElastiCache Redis | Cache | Chưa chốt | `IF-015` |
+| 12 | Cart&Order/Payment → SQS FIFO/EventBridge | Queue (publish) | N/A (managed) | `IF-009` |
+| 13 | Nhóm Hỗ trợ ← SQS FIFO/EventBridge | Queue (consume) | N/A (managed) | `IF-009` |
+
+---
+
+## 7. Deployment view
+
+*Cái gì chạy ở đâu, mấy bản, ranh giới mạng, ranh giới tin cậy. AWS `ap-southeast-1`, đối chiếu
+`TCO_e-commerce_v1.0.md §3.2` (P2, kịch bản A/B).*
+
+```mermaid
+flowchart TB
+    subgraph INTERNET["Internet"]
+        Users["Guest/Customer/Seller/Admin"]
+        ExtPay["VNPay · Momo"]
+        ExtShip["GHN · GHTK"]
+        ExtNotif["Email/SMS Provider"]
+    end
+
+    subgraph AWS["AWS ap-southeast-1"]
+        subgraph PublicSubnet["Public subnet"]
+            WAF["WAF"]
+            ALB["ALB"]
+            CF["CloudFront"]
+            NAT["NAT Gateway (2 AZ)"]
+        end
+        subgraph PrivateApp["Private subnet — ứng dụng"]
+            subgraph ECSMono["ECS Fargate — Modular Monolith\n(⚠️ TCO tính gộp 1 dòng compute — xem OQ-026)"]
+                ECSGD["Nhóm Giao dịch\n(tasks — số theo TCO §3.2, chưa tách riêng)"]
+                ECSHT["Nhóm Hỗ trợ\n(tasks — số theo TCO §3.2, chưa tách riêng)"]
+            end
+            ECSPay["ECS Fargate — Payment Service\n(mạng riêng, IAM riêng)"]
+        end
+        subgraph PrivateData["Private subnet — dữ liệu"]
+            RDSMain[("RDS PostgreSQL Multi-AZ chính\nA: r6g.xlarge · B: r6g.2xlarge + 1 read replica")]
+            RDSPay[("RDS PostgreSQL Multi-AZ Payment\nA: t4g.medium · B: r6g.large")]
+            Redis[("ElastiCache Redis\nA: r6g.large ×1 · B: r6g.xlarge ×1 + 1 replica")]
+        end
+        SQS[("SQS FIFO + EventBridge")]
+        S3[("S3")]
+    end
+
+    Users -->|HTTPS| WAF --> ALB --> ECSGD
+    ALB --> ECSHT
+    ALB --> ECSPay
+    ECSGD --> RDSMain
+    ECSHT --> RDSMain
+    ECSPay --> RDSPay
+    ECSGD --> Redis
+    ECSGD --> SQS
+    ECSPay --> SQS
+    SQS --> ECSHT
+    ECSGD -->|"IF-021/IF-022, REST sync — cross-network (OQ-028)"| ECSHT
+    ECSGD --> S3
+    CF --> S3
+    ECSGD -.-> NAT
+    ECSHT -.-> NAT
+    ECSPay -.-> NAT
+    ECSPay --> ExtPay
+    ECSHT --> ExtShip
+    ECSHT --> ExtNotif
+```
+
+| Thành phần | Môi trường | Số bản *(A / B — `TCO §3.2`)* | Cấu hình | Vùng/AZ | Ranh giới tin cậy |
+|---|---|---|---|---|---|
+| WAF + ALB | Prod | Managed (không đếm instance) | — | Multi-AZ | Ranh giới internet → VPC |
+| ECS Fargate — Modular Monolith *(⚠️ xem `OQ-026`)* | Prod | A: ~4 tasks×1vCPU/2GB · B: ~10 tasks×1vCPU/2GB | Auto-scaling theo CPU/request count | Multi-AZ (private subnet) | Ranh giới VPC nội bộ — chưa tách riêng ranh giới mạng con giữa Nhóm Giao dịch/Nhóm Hỗ trợ. **v1.2:** `IF-021`/`IF-022` là cross-network REST giữa `ECSGD`↔`ECSHT` (cùng VPC, khác ECS service) — cơ chế kết nối thật (service discovery/internal LB, security group) **chưa thiết kế**, thuộc hoạt động `inf` (chưa chạy) |
+| ECS Fargate — Payment Service | Prod | A: 2 tasks×0,5vCPU/1GB · B: 4 tasks×0,5vCPU/1GB | Mạng/IAM riêng — không chung security group với monolith | Multi-AZ (private subnet riêng) | Ranh giới tin cậy cao nhất — PCI-DSS SAQ A (`ASR-002`) |
+| RDS chính | Prod | A: `r6g.xlarge` Multi-AZ · B: `r6g.2xlarge` Multi-AZ + 1 read replica | schema-per-module | Multi-AZ | Chỉ Nhóm Giao dịch/Nhóm Hỗ trợ truy cập |
+| RDS Payment | Prod | A: `t4g.medium` Multi-AZ · B: `r6g.large` Multi-AZ | Riêng biệt hoàn toàn | Multi-AZ | Chỉ Payment Service truy cập |
+| ElastiCache Redis | Prod | A: `r6g.large` ×1 · B: `r6g.xlarge` ×1 + 1 replica | Session/ownership/giỏ hàng | Multi-AZ | Chỉ Nhóm Giao dịch truy cập |
+| SQS FIFO + EventBridge | Prod | Managed | Message group = `seller_id` | Managed (không AZ cụ thể) | Ranh giới publish (GD/Payment) vs consume (HT) |
+| S3 + CloudFront | Prod | Managed | ~500GB (A) / ~1,5TB (B) | Managed | Public read (asset) vs private (KYC — chỉ Seller Mgmt/Admin) |
+| Non-prod (dev/stg) | Dev/Stg | ~35% Production (`TCO §3.2`) | Cấu hình thu nhỏ | ap-southeast-1 | Tách VPC/account với Production (chưa chốt — ứng viên `inf`) |
+
+🔴 **`OQ-026` (mới):** `TCO §3.2` tính chi phí compute ECS Fargate P2 gộp thành **một dòng
+"monolith"** (~4 tasks kịch bản A / ~10 tasks kịch bản B), không tách riêng số task cho "Nhóm
+Giao dịch" và "Nhóm Hỗ trợ" như `ASR-001`/`ASR-014`/`OPT §3` mô tả (2 nhóm ECS Fargate riêng để
+scale độc lập). Đây có thể chỉ là cách gộp số để tính chi phí (2 nhóm vẫn cộng lại đúng tổng
+task), hoặc có thể phản ánh việc `TCO` thực sự mô hình hoá **1 ECS service duy nhất** cho toàn bộ
+monolith (không tách nhóm) — hai cách hiểu cho ra kết luận khác nhau về khả năng scale độc lập
+Nhóm Giao dịch theo `DRV-04`. **Không tự đổi số `TCO`** — ghi nhận lệch mức chi tiết ở đây, cần
+Tech Lead/Ops xác nhận ở hoạt động `inf` trước khi AG2. Nếu xác nhận là 1 ECS service duy nhất:
+`ASR-014`/`ADR-012` phải viết lại phần "2 nhóm ECS Fargate riêng để scale nhanh hơn" thành "2
+nhóm logic trong cùng 1 ECS service, scale chung" — ảnh hưởng trực tiếp khả năng đáp ứng
+`ASR-001`/tiêu chí "Đáp ứng DRV Must" đã chấm ở `OPT §4`.
+
+🔴 **Cập nhật v1.2 (`OQ-028`):** sơ đồ deployment trước đây (v1.0/v1.1) **thiếu cạnh mạng** giữa
+`ECSGD` và `ECSHT` dù Container diagram (§4, mũi tên "11") và Component diagram (§5, mũi tên "21")
+đã thể hiện `Cart&Order` gọi `Promotion&Loyalty` qua REST — nay bổ sung cạnh này (nhãn
+`IF-021`/`IF-022`) để hết mâu thuẫn nội bộ. Cơ chế kết nối thật (service discovery/internal load
+balancer, security group giữa 2 ECS service) **chưa được thiết kế** — thuộc hoạt động `inf` (hoạt
+động 7, chưa chạy). Không tự thêm hạ tầng mới (VD internal ALB/App Mesh) vào sơ đồ vì đó là quyết
+định kiến trúc mới, ngoài phạm vi "chỉ sửa lỗi nhất quán" của lượt chạy này.
+
+---
+
+## 8. Quyết định kiến trúc đã ghi *(12 `ADR` đã viết ở hoạt động `adr` — 2026-09-15)*
+
+*Cập nhật ở SAD v1.1 theo `DEC-17`: 12 `ADR` ứng viên dưới đây (đã duyệt từng phần ở
+`ASR_e-commerce_v1.0.md §B2`/`DEC-14`) nay đã được viết thành file thật trong
+`02-architecture/adr/`. **Không đổi số thứ tự, không đổi radar ước lượng** so với bảng đã duyệt.
+Tất cả giữ `Status: Proposed` — chưa ADR nào `Accepted` vì chưa có chữ ký Tech Lead + Security +
+Ops/SRE thật.*
+
+| `ADR` | Quyết định | File | Status | Radar | Cần POC/bài đo trước `Accepted`? |
+|---|---|---|---|---|---|
+| `ADR-001` | Kiểu kiến trúc tổng thể — Modular Monolith P2, không phải Microservices P1 | `adr/ADR-001_kieu-kien-truc-tong-the-modular-monolith-p2.md` | `Proposed` | ~7 | Có — `POC-01`/`POC-02` (dưới ngưỡng 8 cứng nhưng `ASM-07`/`08` chưa xác minh) |
+| `ADR-002` | Payment Service là biên cô lập PCI-DSS SAQ A | `adr/ADR-002_payment-service-bien-co-lap-pci-dss.md` | `Proposed` | ~7 | Không bắt buộc POC (ràng buộc pháp lý) — cần Security ký |
+| `ADR-003` | Mô hình `Order`/`OrderSeller` — tách đơn theo seller | `adr/ADR-003_mo-hinh-order-orderseller-tach-don-theo-seller.md` | `Proposed` | ~6 | Không — nhưng chờ `OQ-011` (BA) |
+| `ADR-004` | Cơ chế idempotency & đối soát cho webhook thanh toán | `adr/ADR-004_idempotency-doi-soat-webhook-thanh-toan.md` | `Proposed` | ~6 | Không bắt buộc — chờ sandbox VNPay/Momo thật |
+| `ADR-005` | Message backbone — SQS FIFO + EventBridge | `adr/ADR-005_message-backbone-sqs-fifo-eventbridge.md` | `Proposed` | **~8** | **Có — bắt buộc `POC-01`, chưa chạy** |
+| `ADR-006` | Chiến lược dữ liệu — RDS gộp schema-per-module | `adr/ADR-006_chien-luoc-du-lieu-rds-gop-schema-per-module.md` | `Proposed` | **~8** | **Có — bắt buộc `POC-02`, chưa chạy** |
+| `ADR-007` | Chỗ ra quyết định ownership/authz — service + cache Redis | `adr/ADR-007_cho-quyet-dinh-ownership-authz-cart-order.md` | `Proposed` | ~6 | Không — khuyến nghị đo lại `QAS-003`/`004` |
+| `ADR-008` | Vùng lưu trữ PII & chính sách chia sẻ cho seller | `adr/ADR-008_vung-luu-tru-pii-chinh-sach-chia-se-seller.md` | `Proposed` | ~7 | Phủ quyết Security/Legal — chặn hoàn toàn tới khi có người (`OQ-007`) |
+| `ADR-009` | Chiến lược HA/DR cho nhóm dịch vụ giao dịch lõi | `adr/ADR-009_chien-luoc-ha-dr-dich-vu-giao-dich-loi.md` | `Proposed` | **~9** | **Có — bắt buộc diễn tập DR, chưa chạy, điều kiện tiên quyết AG2 (`OQ-022`)** |
+| `ADR-010` | Kiến trúc observability & alerting | `adr/ADR-010_kien-truc-observability-alerting.md` | `Proposed` | ~6 | Không bắt buộc |
+| `ADR-011` | Chính sách resilience đối tác thanh toán/vận chuyển | `adr/ADR-011_chinh-sach-resilience-doi-tac-ngoai.md` | `Proposed` | ~6 | Không bắt buộc — chờ sandbox 4 đối tác |
+| `ADR-012` | Ranh giới nhóm triển khai theo domain và năng lực đội | `adr/ADR-012_ranh-gioi-nhom-trien-khai-theo-domain.md` | `Proposed` | ~7 | Không — chờ `OQ-010` (số đội thật) + `OQ-026`/`OQ-027` (khớp `TCO`, vị trí Identity) |
+| `ADR-013` | Bất đồng bộ hoá bước khởi tạo thanh toán trong checkout (Lựa chọn B của `OQ-034`, hiện thực hoá §6.1 v1.3) | `adr/ADR-013_bat-dong-bo-hoa-khoi-tao-thanh-toan.md` | `Proposed` | 7 | Không bắt buộc (dưới ngưỡng 8) — khuyến nghị chạy `FIT-23` (chaos đo p95) trước go-live; bắt buộc Tech Lead + PO **thật** xác nhận (không chỉ ký thay) trước `Accepted` |
+
+*Sổ đầy đủ: `../00-index/ADL_e-commerce.md` §2 — mục lục 13 ADR đã đồng bộ theo lượt chạy
+`adr` 2026-09-15 (12 ADR ban đầu + `ADR-013` bổ sung cùng ngày, hoạt động `adr`, phạm vi hẹp).*
+
+---
+
+## 9. Mối quan tâm xuyên suốt
+
+| Mối quan tâm | Quyết định | Ở đâu | `ADR` |
+|---|---|---|---|
+| Định dạng log & correlation id | Chưa chốt | `AGD` (GĐ3) | `ADR-010` (ứng viên) |
+| Xử lý lỗi & mã lỗi | Đề xuất kế thừa `API_US002-003` §2 (`{error:{code,message,details}, traceId}`) — chưa xác nhận BE | `ICD` (hoạt động 4) | — |
+| Xác thực & phân quyền | JWT (Customer) / `X-Guest-Session-Id` (Guest), MFA Admin = TOTP app (**tạm**, `OQ-024` mở) | `SEC` (hoạt động 6) | `ADR-007` (ứng viên) |
+| Cấu hình & secret | Chưa chốt | `SEC`, `INF` (hoạt động 6–7) | — |
+| Múi giờ & định dạng thời gian | Chưa có trường thời gian nào ở phạm vi Cart (`API_US002-003 §1`) — chốt khi mở rộng sang Order lifecycle | `ICD` | — |
+| Số lớn (id/tiền) | `string` cho mọi id (khớp đề xuất BA `API_US002-003 §1`, khớp ví dụ SAD gốc) | `ICD` | — |
+| Đa ngôn ngữ | UI hệ thống có i18n; nội dung seller tự nhập **không dịch ở MVP (tạm)**, `OQ-025` mở | `AGD` (GĐ3), `DAT` nếu đổi | — (borderline, `ASR-015`) |
+| Idempotency | `Idempotency-Key` bắt buộc cho `POST /v1/checkout` (khớp `04-api-design.md §4.1.1`); webhook idempotent theo `gateway_transaction_ref` (`ASR-004`) | `ICD`, `FAIL` (hoạt động 4, 8) | `ADR-004` (ứng viên) |
+
+---
+
+## 10. Giả định & Ngoài phạm vi
+
+**Giả định** *(tiếp số toàn dự án — `ASM-01…21` đã dùng ở `CTX`/`OPT`/`TCO`/`QAS`/`ASR`, bắt đầu `ASM-22`)*:
+
+| ID | Giả định | Cách xác minh | Nếu sai |
+|---|---|---|---|
+| `ASM-22` | Identity & Access được xếp vào **Nhóm Giao dịch** (không phải nhóm riêng) — suy từ `ASR-010`/`ASR-011` (nhóm "giao dịch cốt lõi" = Payment + Cart&Order + Identity cho HA/DR/observability), dù `OPT §3`/`ASM-19` chỉ nêu rõ Catalog/Cart&Order cho "nhóm giao dịch" (scale) mà không nhắc Identity | Tech Lead xác nhận lại tại hoạt động `sad` kế tiếp/khi rà `ADR-012`, cùng lúc với `OQ-010` | `CMP-02`/§4.1, §7 — nếu Identity thực ra nên là nhóm riêng hoặc thuộc Nhóm Hỗ trợ, đổi cột "Nhóm triển khai" và deployment view §7 |
+| `ASM-23` | `TCO §3.2` dòng compute "monolith" phản ánh **tổng số task** của cả Nhóm Giao dịch và Nhóm Hỗ trợ cộng lại (2 ECS service logic vẫn tồn tại, chỉ gộp số để tính tiền), không phải 1 ECS service duy nhất | Ops/Tech Lead xác nhận ở hoạt động `inf` (`OQ-026`) | Nếu sai (là 1 service duy nhất): `ASR-014`/`ADR-012` phải viết lại phần "scale độc lập theo nhóm"; ảnh hưởng đáp ứng `DRV-04`/tiêu chí `OPT §4` |
+
+*`ASM-01…21` của `CTX`/`OPT`/`TCO`/`QAS`/`ASR` vẫn áp dụng nguyên trạng — không lặp lại nội
+dung, chỉ tham chiếu (đặc biệt `ASM-07`→`ADR-005`, `ASM-08`→`ADR-006`, `ASM-19`→`ADR-012`,
+`ASM-20`→`CMP-02` MFA, `ASM-21`→`CMP-09`/`CMP-03` i18n).*
+
+**Ngoài phạm vi** *(quy tắc `D11`)*:
+
+- `ADR`, `ICD`, `DAT`, `SEC`, `INF`, `FAIL` chính thức — chưa thực hiện ở lượt chạy này (chỉ hoạt
+  động `sad`). Mọi bảng "ứng viên" ở §4.1, §6.3, §9 là đầu vào, không phải kết luận cuối.
+- Component mức 3 (§5) chỉ vẽ cho container "Nhóm Giao dịch" (Cart & Order) — các container khác
+  (Nhóm Hỗ trợ, Payment Service) chưa có Component diagram riêng, theo đúng khuyến nghị
+  `SKILL.md` ("không vẽ mức Component cho mọi container").
+- OpenSearch — **không** đưa vào deployment view P2 vì `TCO §3.2`/`OPT §3` P2 hoãn dùng managed
+  OpenSearch, dùng Postgres full-text search giai đoạn đầu; chuyển sang OpenSearch khi có bằng
+  chứng tải thật cần (ngưỡng xét lại: traffic thật tiệm cận kịch bản B ×2, theo `QAS-009`).
+  Không tự thêm OpenSearch vào sơ đồ vì `TCO`/`OPT` không tính chi phí đó cho P2 kịch bản A/B.
+- Google/Facebook OAuth — không vẽ ở Context (§3) theo đúng phạm vi bắt buộc của ghi chú người
+  duyệt (chỉ 5 hệ ngoài: VNPay/Momo/GHN/GHTK/Email-SMS); vẫn thuộc Identity & Access ở mức
+  Container/Component khi triển khai chi tiết (ngoài phạm vi tài liệu này).
+- Kiến trúc này (P2) không nhắm tới tải vượt kịch bản B (10.000 concurrent) ×2 mà chưa kiểm
+  chứng lại bằng `POC`/bài đo thật — kế thừa nguyên trạng từ `QAS-009`/`OPT §1`.
+- Ranh giới mạng con (subnet) chi tiết giữa Nhóm Giao dịch và Nhóm Hỗ trợ trong cùng `ECSMono` —
+  chưa thiết kế (thuộc hoạt động `inf`); hiện chỉ tách Payment ra ranh giới mạng riêng theo
+  `ASR-002`.
+
+## 11. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Hệ quả nếu trả lời ngược |
+|---|---|---|---|---|---|
+| `OQ-026` | `TCO §3.2` tính compute ECS Fargate P2 là 1 dòng "monolith" gộp — có đúng là 2 ECS service riêng (Nhóm Giao dịch/Nhóm Hỗ trợ, như `ASR-001`/`ASR-014`/`OPT §3` mô tả) hay chỉ 1 ECS service duy nhất chưa tách nhóm? | Tech Lead + Ops/SRE | 2026-09-15 | §7 deployment view; `ADR-012`; khả năng đáp ứng `DRV-04` (scale-out độc lập Catalog/Cart&Order) | Nếu là 1 service duy nhất: mất khả năng scale riêng Nhóm Giao dịch khi flash sale — phải sửa `TCO` (thêm chi phí tách thành 2 service) hoặc chấp nhận scale chung (giảm điểm tiêu chí "Đáp ứng DRV Must" đã chấm P2=4 ở `OPT §4`, cần chấm lại) |
+| `OQ-027` | Identity & Access nên thuộc Nhóm Giao dịch (theo suy luận `ASM-22` từ `ASR-010`/`011`) hay là một nhóm triển khai riêng/thuộc Nhóm Hỗ trợ? `OPT §3` không nói rõ vị trí của Identity trong 2 nhóm ECS đề xuất. | Tech Lead | 2026-09-15 | `CMP-02`, §4.1 cột "Nhóm triển khai", §7 deployment view, `ADR-012` | Nếu Identity thuộc Nhóm Hỗ trợ: giảm mức độ cô lập HA/DR của `ASR-010` (Identity chung nhóm scale với các module ít quan trọng hơn) — cần đánh giá lại RPO/RTO ở hoạt động `inf` |
+
+**Nhắc:** cộng với các `OQ` còn mở ảnh hưởng trực tiếp `SAD` — `OQ-010` (số đội thật, chặn
+`ASR-014`/`ADR-012`), `OQ-012` (thời điểm `POC-01`, chặn `ADR-005`), `OQ-007` (đại diện Pháp
+chế, chặn `ADR-008`), `OQ-022` (lịch diễn tập DR, điều kiện tiên quyết AG2), `OQ-024`/`OQ-025`
+(MFA Admin, phạm vi i18n — đã chốt TẠM, giữ mở) — xem sổ đầy đủ `00-index/OQ_e-commerce.md`.
+
+**Nhắc AG2:** cần **Tech Lead + Security + Ops/SRE ký** — còn xa vì `ICD`/`DAT`/`SEC`/`INF`/
+`FAIL` (hoạt động 4–8) và toàn bộ `ADR-001…012` (hoạt động 9) chưa chạy/chưa viết.
+
+---
+
+## Tự chấm
+
+### ① Bảng tự chấm Gate AG2 *(`workflow.md §2` — chỉ dòng liên quan tới `SAD`, tự chấm sớm)*
+
+| # | Tiêu chí | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| — | `ASR` liệt kê yêu cầu định hình kiến trúc | ✅ *(đã đạt ở hoạt động `asr` trước)* | Xem `ASR_e-commerce_v1.0.md` |
+| — | `QAS` — mọi NFR đã lượng hoá | ✅ *(đã đạt ở hoạt động `qas` trước)* | Xem `QAS_e-commerce_v1.0.md` |
+| 1 | `SAD` có sơ đồ C4 mức Context và Container, có deployment view, mỗi `CMP-nn` ghi rõ trách nhiệm | ✅ | §3 (Context), §4 (Container + `CMP-01…15`), §5 (Component — Cart&Order), §7 (Deployment) |
+| 2 | `ADR-nnn` tồn tại cho mọi quyết định đạt ngưỡng radar | ☐ | **Chưa viết `ADR` nào** — đúng theo yêu cầu điều phối; 12 chỗ chờ đã đánh dấu ở §8 với radar ước lượng kế thừa từ `ASR` |
+| — | `ICD`/`DAT`/`SEC`/`INF`/`FAIL` | ☐ | Chưa tới — hoạt động 4–8. Đã để lại ứng viên: `IF-nnn` (§4.1, §6.3), thực thể dữ liệu (§4.1 cột "Dữ liệu sở hữu"), phụ thuộc cần `FAIL` (§6.3) |
+| — | `sa-conformance` báo coverage `ASR → ADR/CMP` ≥ 100% | 🟡 Một phần | `ASR → CMP` đạt 15/15 (§4.3); `ASR → ADR` vẫn 0/12 vì chưa viết `ADR` nào — kỳ vọng đúng lúc này, sẽ chặn AG2 thật nếu vẫn 0/12 khi hoạt động `adr` chạy xong |
+
+**Kết luận tự chấm (riêng phần `SAD`):** Hoạt động `sad` hoàn tất đúng phạm vi được giao — C4 đủ
+3 mức (Context/Container/Component cho phần phức tạp nhất), deployment view đối chiếu `TCO` (1
+điểm lệch đã ghi `OQ-026`, không tự sửa), `CMP`/ma trận `ASR×CMP` đủ 15/15, không `CMP` mồ côi.
+AG2 **còn xa** vì 5/9 hoạt động khác của GĐ2 (`icd`/`dat`/`sec`/`inf`/`fail`) và hoạt động `adr`
+(viết 12 `ADR` đã đánh dấu) chưa chạy — đây là tiến độ kỳ vọng, không phải lỗi.
+
+### ② Checklist D1–D12 *(`design-rules.md`)*
+
+| # | Mục | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| D1 | Một ADR một quyết định | N/A | Tài liệu này không viết `ADR` — chỉ đánh dấu 12 chỗ chờ, mỗi chỗ đã tách đúng 1 quyết định (kế thừa từ `ASR §B2`) |
+| D2 | Không NFR định tính; đủ 4 câu | N/A | `SAD` không phải `QAS` — mọi số liệu (deployment §7) tham chiếu đúng `TCO`/`QAS` đã lượng hoá, không tự đặt số mới |
+| D3 | Nêu phương án bị loại + lý do gắn `CON`/`QAS` | ✅ *(kế thừa)* | §2 tham chiếu `OPT §5` (P1/P3/P4 đã loại); không lặp lại nội dung, chỉ dẫn |
+| D4 | Sơ đồ khai báo mức + legend | ✅ | §3/§4/§5/§7 mỗi sơ đồ đều khai báo mức C4 (Context/Container/Component/Deployment) + có legend, không trộn mức |
+| D5 | Interface có chủ/contract | 🟡 Một phần | §4.1/§6.3 đã ghi 17 `IF-nnn` ứng viên *(sửa từ "22" ở v1.2 — đếm nhầm, xem `OQ-029`)* với hai đầu + giao thức + sync/async, nhưng "ai sở hữu contract"/"đường dẫn contract thật"/"versioning policy" chưa chốt — đúng phạm vi, để hoạt động `icd` (hoạt động 4) |
+| D6 | Phụ thuộc ngoài process có timeout/retry | 🟡 Một phần | §6.3 liệt kê đủ 13 phụ thuộc vượt ranh giới process, nhưng timeout/retry/idempotent đầy đủ theo 4 câu hỏi `D6` thuộc hoạt động `fail` (hoạt động 8), chưa chạy |
+| D7 | Một chủ sở hữu dữ liệu | ✅ *(ở mức khối)* | §4.1 mỗi `CMP` ghi đúng 1 tập thực thể sở hữu, không trùng lặp giữa các `CMP`; chi tiết consistency/retention để `DAT` (hoạt động 5) |
+| D8 | Ràng buộc có FIT hoặc nhãn khuyến nghị | N/A | Chưa tới `AGD`/`FIT` (GĐ3) |
+| D9 | Con số hạ tầng quy ra tiền + nguồn; `INF` khớp `TCO` | 🟡 Một phần | §7 dùng đúng số của `TCO §3.2` (có nguồn); phát hiện 1 điểm lệch mức chi tiết (ECS gộp vs tách nhóm) — ghi `OQ-026`, không tự đổi số, đúng theo `D9` "lệch thì TCO sai hoặc INF sai, không có khả năng thứ ba" (ở đây là SAD/TCO cần làm rõ mức chi tiết, chưa hẳn là sai) |
+| D10 | Không quyết định thay người có thẩm quyền | ✅ | `ASM-22`/`OQ-027` (vị trí Identity) và `OQ-026` (khớp TCO) đều trình dưới dạng câu hỏi kèm hệ quả, không tự quyết; `ADR-008` (PII) tiếp tục ghi rõ phủ quyết thuộc Security/Legal |
+| D11 | Có mục "Ngoài phạm vi" + `ASM-nn` | ✅ | §10 đầy đủ — `ASM-22/23` mới, có cách xác minh/hệ quả; "Ngoài phạm vi" liệt kê rõ OpenSearch/OAuth/subnet chi tiết chưa làm |
+| D12 | Câu quy định thẩm quyền sơ đồ vs văn bản | ✅ | Có ngay sau Change Log |
+
+### ③ Bảng đối chiếu với bộ BA
+
+| `BA` | Nội dung | `SA` tương ứng | Khớp? | Hành động |
+|---|---|---|---|---|
+| `PROCESS_CartCheckout` B1–B9 | Luồng checkout, tách đơn, chờ webhook | §6.1/§6.2 (sequence diagram) | ✅ | Không lệch — SAD hiện thực hoá đúng thứ tự bước đã có ở BA, thêm chi tiết component/hạ tầng |
+| `IMPACT_CartCheckout` §1.5 | Tích hợp VNPay/Momo (🔴), GHN/GHTK (🟠), Catalog nội bộ (🟠), Promotion&Loyalty nội bộ (🟠) | §3 Context (4 hệ ngoài bắt buộc) + §4 Container (mũi tên 5, 11, 12, 13) | ✅ | Không lệch — mọi điểm tích hợp BA nêu đều có mặt ở Container/Context |
+| `IMPACT_CartCheckout` §1.5 câu hỏi mới (Promotion&Loyalty lỗi thì bỏ qua hay chặn checkout) | Chưa chốt ở BA | §6.1 bảng bước "Áp dụng coupon/điểm" ghi "chưa chốt hành vi" | 🟡 Một phần | **BA cập nhật `IMPACT_CartCheckout` §6** khi có câu trả lời — SAD đã phản ánh đúng trạng thái "chưa chốt", không tự giả định |
+| `API_US002-003` (BA đề xuất) | 3 endpoint `GET/PATCH/DELETE /v1/cart*`, quy ước `id` dạng string, `Idempotency-Key` cho ghi | §9 Mối quan tâm xuyên suốt (số lớn, idempotency); §4.1 `CMP-04` sở hữu `Cart`/`CartItem` | ✅ | Không lệch — `ICD` (hoạt động 4) sẽ là nơi xác nhận chính thức theo `artifact-map.md §7` ("`ICD` thắng `API`") |
+| `docs/sections/03-kien-truc.md` §3.1 | ~10 microservices (P1, đã loại) | §2/§4 — modular monolith P2, **không** kế thừa số lượng/kiểu service của P1 | ✅ Đúng yêu cầu | Chỉ tái dùng danh sách 9 domain module + 5 tích hợp ngoài, không tái dùng kiểu kiến trúc — đúng ghi chú người duyệt |
+
+### ④ Danh sách `OQ` mở kèm người phải trả lời, chặn gì
+
+Xem §11 (`OQ-026`, `OQ-027` mới) cộng các `OQ` còn mở từ `CTX`/`OPT`/`TCO`/`ARISK`/`QAS`/`ASR` —
+sổ đầy đủ tại `00-index/OQ_e-commerce.md`. Ba câu quan trọng nhất cho AG2: **`OQ-012`** (`POC-01`
+chặn `ADR-005`), **`OQ-022`** (diễn tập DR, điều kiện tiên quyết AG2), **`OQ-007`** (đại diện
+Pháp chế, chặn `ADR-008`).
+
+**Nhắc:** AG2 cần **Tech Lead + Security + Ops/SRE ký** — còn xa. Hoạt động kế tiếp có thể chạy
+song song: `icd` (dùng 17 `IF-nnn` ứng viên ở §4.1/§6.3, sửa từ "22" ở v1.2 — xem `OQ-029`), `dat` (dùng bảng "Dữ liệu sở hữu" ở
+§4.1), `sec` (dùng §9 mô hình xác thực/phân quyền sơ bộ), `inf` (dùng §7 deployment view, phải
+giải quyết `OQ-026` trước khi chốt), `fail` (dùng §6.3 danh sách phụ thuộc).