Files

Canhchimlac 343ad8bbbc save

2026-09-15 16:02:30 +07:00

48 KiB

Raw Permalink Blame History

OPT — Solution Options & Trade-off — e-commerce


Version	1.0
Date	2026-09-12
Author	SA (skill sa-1-context, chế độ `go`, hoạt động `options`)
Status	🟡 Draft (duyệt từng phần — xem `Approved by`; §1 Khuyến nghị, §2 Bộ tiêu chí và trọng số mặc định (đóng `ASM-09`), §4 Bảng chấm điểm, §5 Phương án bị loại (P3/P4) đã được duyệt tạm để làm nền cho Bước 5/GĐ2 — chọn P2 có điều kiện (`OQ-010`, `OQ-012`); đây chưa phải AG1 toàn phần — Tech Lead chưa ký, `OQ-004` còn mở, quyết định kiến trúc chính thức (`ADR`) vẫn để GĐ2; xem "Tự chấm" §① — vẫn 4/7 tiêu chí ✅)
Approved by	PO (uỷ quyền, chế độ chạy thử): Điều phối dự án — duyệt từng phần bản v1.0 · 2026-09-12: chấp nhận bộ tiêu chí và trọng số mặc định (§2, đóng `ASM-09`), bảng chấm điểm (§4), hai phương án bị loại P3/P4 (§5), và khuyến nghị P2 có điều kiện (§1). Chọn P2 (modular monolith + managed AWS, tách riêng Payment) làm nền cho Bước 5 và GĐ2, điều kiện: (1) `OQ-010` — Tech Lead xác nhận đội thi công thật; (2) POC SQS/EventBridge được ghi vào `ARISK` ở Bước 5 (`OQ-012`), trước khi chốt `ADR` message backbone GĐ2. Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-06`; không phải chữ ký PO/Tech Lead thật — `OQ-004` giữ mở. Duyệt này vẫn là duyệt từng phần, không phải AG1 toàn phần, và không thay thế yêu cầu `ADR` chính thức ở GĐ2 (kiểu kiến trúc tổng thể là quyết định thuộc danh mục bắt buộc ADR theo `decision-radar.md §3`). · Tech Lead: — (chưa ký)
Source	`01-context/CTX_e-commerce_v1.0.md` (v1.2 trong header) §2 (`DRV-01…09`), §3 (`CON-01…09`), §4.2 (đối tác 🔴), §4.4 (năng lực tổ chức) · `e-commerce/docs/SAD.md` v0.2 §3.1–§3.4 (`e-commerce/docs/sections/03-kien-truc.md`) · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` (FR/NFR) · `e-commerce/bid/estimate.computed.json` (Draft, `priceComplete:false`) · `e-commerce/bid/bid-config.md` (Draft) · `00-index/OQ_e-commerce.md` v1.4 · `00-index/DEC_e-commerce.md` v1.4
Scope	Toàn sàn e-commerce (marketplace đa seller) theo `SAD.md` v0.2 — phạm vi đã chốt cho lượt chạy này; `OQ-003` (giữ toàn sàn hay thu hẹp về Giỏ hàng & Checkout) vẫn mở, chưa ảnh hưởng cấu trúc phương án ở đây vì cả ba phương án đều mô tả ở mức kiến trúc tổng thể toàn sàn
Confidence	🔴 Giả định chưa xác minh — kế thừa nguyên nhân của `CTX` (BA chưa ký G1 thật, AG1 GĐ1 SA chưa từng chạy, ngoại lệ gate `DEC-01/03/04` tiếp tục ở `DEC-05`). Riêng phần điểm số ở đây còn thêm hai lý do: (a) `CON-01`/`CON-02`/`CON-05` — ba tiêu chí input trực tiếp cho bảng chấm — đều "Chưa xác định/Mềm" trong `CTX`, chỉ có số tham khảo từ hồ sơ thầu Draft; (b) con số hạ tầng dùng để so sánh P1/P2 ở đây là số lượng/loại thành phần quản lý (managed component), không phải tiền — `TCO` bằng VND thật để Bước 5, ngoài phạm vi lượt chạy này. Duyệt từng phần theo `DEC-06`
không nâng `Confidence` này (phê duyệt không phải bằng chứng nguồn mới) — vẫn chờ `OQ-004`
(tính hợp lệ ký thay), `OQ-010` (kinh nghiệm team thật), `OQ-012` (POC SQS/EventBridge)

Change Log

Version	Date	Người sửa	Thay đổi	ADR/DEC
1.0	2026-09-12	SA (qua skill sa-1-context, chế độ `go`, hoạt động `options`)	Bản đầu — Bước 4 của `sa-1-context`: chốt bộ tiêu chí (từ `DRV`/`CON`), dựng 3 phương án chấm điểm (P0 giữ nguyên, P1 modular microservices theo `SAD.md`/hồ sơ thầu, P2 modular monolith + managed AWS — phương án đối trọng độc lập), 2 phương án bị loại có lý do (P3 mua/tích hợp nền tảng sẵn có, P4 serverless-first). Khuyến nghị P2 có điều kiện — không tự quyết thay PO/Tech Lead (`D10`). Tiếp tục ngoại lệ gate `DEC-01`/`DEC-03`/`DEC-04`, ghi thêm `DEC-05`. Không sửa `CTX` §2–§5 đã duyệt từng phần; chỉ tham chiếu. `Confidence` 🔴 toàn tài liệu.	`DEC-05`
1.0	2026-09-12	PO (uỷ quyền, Điều phối dự án) — tác vụ sign/approve	Duyệt từng phần bản v1.0: chấp nhận bộ tiêu chí và trọng số mặc định (§2, đóng `ASM-09`), bảng chấm điểm (§4), hai phương án bị loại P3/P4 (§5), khuyến nghị P2 có điều kiện (§1). Chọn P2 (modular monolith + managed AWS, tách riêng Payment) làm nền cho Bước 5 và GĐ2, điều kiện: (1) `OQ-010` — Tech Lead xác nhận đội thi công thật; (2) POC SQS/EventBridge (`ASM-07`) ghi vào `ARISK` ở Bước 5, trước khi chốt `ADR` message backbone GĐ2 (`OQ-012`). Không đổi nội dung chuyên môn. Ký thay PO theo ngoại lệ `DEC-01` (SA), ghi thêm `DEC-06`; không phải chữ ký PO/Tech Lead thật — `OQ-004` giữ mở, Tech Lead chưa ký. `Confidence` giữ 🔴. Status giữ 🟡 Draft — AG1 toàn phần vẫn chưa đủ điều kiện (4/7 tiêu chí ✅, xem §①); quyết định kiến trúc chính thức vẫn để `ADR` ở GĐ2, DEC-06 chỉ ghi nhận hướng đi tạm. `OQ-011` đóng trong sổ `00-index/OQ_e-commerce.md` bằng chính câu trả lời có điều kiện này.	`DEC-06`

⚠️ Đây là tài liệu PO + Tech Lead ký để qua AG1. Đọc §1 và §5 là đủ để quyết. Tài liệu này chưa đủ điều kiện baseline AG1 một mình — vẫn thiếu TCO (Bước 5) và ARISK/kế hoạch POC (Bước 5), xem "Tự chấm" ở cuối CTX_e-commerce_v1.0.md §Tự chấm ① (cập nhật lại ở cuối file này).

Sơ đồ thắng về quan hệ và luồng (ai gọi ai, đồng bộ/bất đồng bộ). Bảng/văn bản thắng về ràng buộc và con số (timeout, quyền, đơn vị hạ tầng). Mâu thuẫn ngoài hai loại này là lỗi tài liệu, phải sửa chứ không chọn bên (D12).

0. Ghi chú Preflight & ngoại lệ gate — tiếp nối `CTX`

Gate AG1 (PO + Tech Lead) của chính GĐ1 SA chưa từng chạy cho dự án e-commerce, và BA vẫn chưa ký G1 chính thức (BRIEF_CartCheckout Draft) — như đã ghi ở CTX §0, DEC-01, DEC-03, DEC-04. Người dùng (vai điều phối dự án chạy thử) tái khẳng định muốn tiếp tục sang Bước 4 (OPT) của sa-1-context dù các điều kiện trên chưa đạt.

DEC-05 (SA) — Tiếp tục chạy sa-1-context Bước 4 (Phương án — OPT) cho dự án e-commerce trong khi BA vẫn chưa qua G1 và AG1 (gate của chính GĐ1 SA) vẫn chưa từng chạy — tiếp nối DEC-01/DEC-03/DEC-04. Quyết định: Tiếp tục, Confidence 🔴 cho toàn bộ nội dung điểm số (dựa trên CON còn "Chưa xác định/Mềm") cho tới khi có số ngân sách/deadline/team thật (OQ-005, OQ-006, OQ-008). Người quyết: Điều phối dự án (đại diện PO, dự án chạy thử). Radar (ước lượng): ~3–4 (chi phí đảo ngược thấp — nội dung OPT sửa lại khi có số thật không tốn nhiều · bán kính ảnh hưởng: toàn bộ quyết định kiến trúc GĐ2 phụ thuộc phương án chọn ở đây, nhưng bản thân việc ghi tài liệu dưới ngoại lệ thì nhỏ · chưa chạm trực tiếp một QAS cụ thể (QAS chưa tồn tại, đây vẫn là GĐ1) · không ràng buộc dài hạn (ngoại lệ tạm thời) · không tranh cãi mới, tiếp nối tiền lệ) → ghi DEC-nn, không cần ADR theo decision-radar.md §1–§2. Hệ quả nếu không chấp nhận ngoại lệ: dừng sa-1-context ở cuối Bước 3, không có OPT để PO/Tech Lech tham khảo cho tới khi BA ký G1 thật và/hoặc AG1 chạy đủ vòng đầu — chậm tiến độ chạy thử tương ứng.

🔴 Lưu ý quan trọng cho người ký: bảng chấm điểm dưới đây dùng số liệu tham khảo từ hồ sơ thầu (e-commerce/bid/, Draft, priceComplete:false) cho các tiêu chí Chi phí/Thời gian/Team — đây là ước lượng của nhà thầu cho mục đích đấu thầu, không phải số đã được PO xác nhận (OQ-005, OQ-006, OQ-008 vẫn mở). Điểm số vì vậy phản ánh thứ tự tương đối hợp lý giữa các phương án hơn là giá trị tuyệt đối đáng tin cậy.

1. Khuyến nghị (đọc mục này trước)


Phương án khuyến nghị	P2 — Modular monolith + managed AWS services, tách riêng Payment Service
Vì sao	Khớp Conway với team giả định `DEC-02`/hồ sơ thầu (BE trung bình chỉ ~2,6 FTE/tháng trên 7 tháng — xem §3 P2 "Ai vận hành") — 10 service độc lập của P1 vượt quá năng lực vận hành thực tế của một team cỡ này (`CON-05`); đồng thời P2 vẫn giữ nguyên yêu cầu cứng `CON-06` (cô lập Payment Service cho PCI-DSS SAQ A) và không đổi vùng AWS (`CON-03`)
Chỗ phương án này THUA	Thua P1 ở tiêu chí "Đáp ứng `DRV` Must" (4 so với 5) — khả năng scale-out độc lập Catalog/Search khỏi Cart/Checkout (`DRV-04`) yếu hơn khi cả hai còn chung một nhóm deployable ở giai đoạn đầu; đây là đánh đổi thật, không phải P2 thắng tuyệt đối
Điều kiện kèm theo	(1) Tech Lead xác nhận đội thi công thật (không phải đề xuất hồ sơ thầu) — trả lời `OQ-010`; (2) trước khi chốt `ADR` message backbone ở GĐ2, chạy POC đo throughput SQS/EventBridge cho luồng `OrderPlaced`/`PaymentConfirmed` ở tải tương đương `DRV-04` (`ASM-07`, `OQ-012`) — POC fail (không đạt thông lượng cần thiết) ⇒ bổ sung Kafka/MSK riêng cho hot-path đặt hàng (kiến trúc lai), không chuyển hẳn sang P1 vì phần còn lại của P1 (10 service tách rời) vẫn vi phạm Conway; (3) PO xác nhận ngân sách đủ để về sau tách Catalog/Search ra khỏi monolith nếu traffic thật vượt ngưỡng dự kiến (`ASM-08`)
Quyết định này cần ai ký	PO (đánh đổi giữa scale-out sớm và phù hợp năng lực team hiện tại) · Tech Lead (khả thi thi công/vận hành với team thật) — chưa ký, đây vẫn là khuyến nghị của SA, không phải quyết định (`D10`)

2. Bộ tiêu chí (chốt TRƯỚC khi mô tả phương án)

Tiêu chí sinh từ DRV (Must trước) và CON (cứng là điều kiện loại, không phải điểm số). Trọng số dùng nguyên bộ mặc định của sa-1-context/templates/option-tradeoff.md — chưa có buổi duyệt trọng số riêng với PO/Tech Lead (kế thừa hạn chế elicitation của CTX), ghi nhận là giả định tiếp theo.

2.1 Điều kiện loại (gate cứng — pass/fail trước khi chấm điểm)

`CON`	Nội dung	Bắt buộc gì	P0	P1	P2	P3	P4
`CON-03`	Cloud AWS bắt buộc	Không dùng cloud khác/on-prem	N/A (không xây)	✅ Pass	✅ Pass	⚠️ Phụ thuộc bản build nền tảng — hầu hết nền tảng open-source multi-vendor có thể tự host trên AWS, coi là Pass được nếu tự triển khai	✅ Pass (Lambda/Step Functions đều AWS)
`CON-06`	PCI-DSS SAQ A (không lưu thẻ) + NĐ13/2023 (PII/KYC) — Payment phải là biên cô lập duy nhất	Thiết kế phải tách được Payment Service/module ra làm biên cô lập	N/A	✅ Pass — đã thiết kế sẵn trong `SAD.md` §3.1	✅ Pass — Payment tách riêng dù phần còn lại gộp (xem §3 P2)	❌ Không kiểm chứng được với lõi đóng gói sẵn của nền tảng mua/tích hợp mà không sửa sâu — xem §5 lý do loại	⚠️ Chưa kiểm chứng cô lập Payment trong mô hình serverless (Lambda dùng chung VPC/role) — chưa loại nhưng là rủi ro cao, xem §5

Đọc bảng: CON-06 là lý do loại chính của P3. P4 không bị loại bởi gate cứng nhưng bị loại ở bước chấm điểm rủi ro kỹ thuật + thiếu bằng chứng năng lực team (§5).

2.2 Tiêu chí chấm điểm (áp dụng cho phương án đã qua gate cứng)

#	Tiêu chí	Trọng số	Sinh từ	Đo bằng
1	Đáp ứng `DRV` mức Must (`DRV-01,02,03,04,05,06,07,08`)	25%	`DRV-01…08`	Có/không cho từng driver, quy về thang 1–5
2	Chi phí 3 năm (sơ bộ — số lượng/loại managed component, không phải VND; `TCO` VND thật ở Bước 5)	20%	`CON-01` (chưa xác định số thật)	Số lượng thành phần hạ tầng quản lý riêng biệt phải vận hành
3	Thời gian tới bản chạy được	15%	`CON-02` (7 tháng thầu / 9–12 tháng brief)	Effort WBS liên quan tới việc dựng nền tảng (tuần/MD, theo `estimate.computed.json`)
4	Rủi ro kỹ thuật	15%	Nguồn rủi ro "Công nghệ mới"/"Phụ thuộc bên ngoài" (`decision-radar.md`)	Có bằng chứng team từng chạy production công nghệ này chưa (`CTX §4.4`)
5	Phù hợp năng lực team & vận hành (Conway)	15%	`CON-05`, `DEC-02`	Số service/module so với FTE BE trung bình thật (nguồn `estimate.computed.json.mmByRole`)
6	Khả năng tiến hoá (chi phí đảo ngược)	10%	—	Chi phí tách/gộp lại về sau

Trọng số do ai duyệt · ngày: Chưa ai duyệt chính thức — SA dùng bộ mặc định của template vì chưa có buổi làm việc PO/Tech Lech riêng cho trọng số (kế thừa hạn chế elicitation, xem OQ-001 của CTX). Ghi nhận: nếu PO/Tech Lead muốn đổi trọng số (ví dụ tăng "Rủi ro kỹ thuật" hoặc "Chi phí" vì ngân sách hạn chế theo CON-01), chấm lại theo trọng số mới trước khi ký AG1.

🔴 Trọng số này không được chốt trong một buổi làm việc PO xác nhận — nếu điểm tổng P2 so với P1 (§4) đổi thứ hạng khi tăng trọng số "Chi phí" hoặc "Năng lực team" (hai tiêu chí P2 đang mạnh), khuyến nghị càng vững; nếu PO tăng mạnh trọng số "Đáp ứng DRV Must" (tiêu chí P1 mạnh hơn), thứ hạng có thể đổi — xem OQ-011.

3. Các phương án

P0 — Không làm gì / giữ nguyên (mốc so sánh, bắt buộc có)


Mô tả	Không triển khai sàn e-commerce ở giai đoạn này. Vì đây là dự án greenfield (`CTX §4.1`), "giữ nguyên" nghĩa là không có gì để giữ — khách hàng/seller tiếp tục không có nền tảng giao dịch tập trung nào (không có quy trình thủ công đang chạy để so sánh, khác dự án loại "mở rộng")
Chi phí 3 năm	Không phát sinh chi phí xây dựng/vận hành kiến trúc. Chi phí cơ hội không định lượng được ở lượt này — `DRV-01` đã ghi rõ: không có luồng giao dịch ⇒ 0 giao dịch ghi nhận, toàn bộ mô hình kinh doanh marketplace bị chặn hoàn toàn, đây là hệ quả định tính nghiêm trọng nhất trong toàn bộ `CTX`, dù không quy ra được một con số tiền cụ thể (không có doanh thu mục tiêu bằng số trong nguồn hiện có)
Vì sao không chọn	Vi phạm trực tiếp `DRV-01` (Must, blocker) — đây là driver mạnh nhất trong toàn bộ `CTX`. Giữ P0 làm mốc so sánh, không phải phương án khả thi

P1 — Modular microservices theo `SAD.md` v0.2 / hồ sơ thầu (điểm khởi đầu tham khảo, `DEC-04`)


Ý tưởng một câu	~10 service theo bounded-context, database-per-service, giao tiếp REST đồng bộ + Kafka/MSK bất đồng bộ cho chuỗi nghiệp vụ sau đặt hàng
Thành phần chính	Identity, Catalog & Inventory, Search (OpenSearch), Cart & Order (+ Dispute), Payment, Seller Management, Commission & Payout, Promotion & Loyalty, Review, Notification, Shipping & Fulfillment — mỗi service một RDS PostgreSQL Multi-AZ logic riêng, ElastiCache Redis dùng chung cho cache/session/giỏ hàng, Kafka/MSK là xương sống bất đồng bộ, ECS Fargate/EKS auto-scaling theo domain, CloudFront + WAF phía trước
Mua gì / tự làm gì	Toàn bộ business logic tự xây; hạ tầng dùng AWS managed service (RDS, MSK, ElastiCache, OpenSearch, ECS/EKS, CloudFront, WAF) — không mua phần mềm lõi thương mại nào
Dữ liệu nằm ở đâu, ai sở hữu	Mỗi service sở hữu schema/DB riêng (database-per-service) — không service nào truy cập trực tiếp DB service khác, chỉ qua API/event (`SAD.md §3.2`)
Ai vận hành	Đội DevOps/SRE phải vận hành ~10 service group riêng + 1 cụm Kafka/MSK + 1 cụm OpenSearch đa node — theo hồ sơ thầu, FTE DevOps trung bình toàn dự án chỉ ~4,92 MM/~7 tháng ≈ 0,7 FTE trung bình (`estimate.computed.json.mmByRole.DEVOPS`), đỉnh điểm cao hơn ở WBS-01/02/03
Thời gian tới bản chạy được	Riêng hạng mục nền tảng dịch vụ & event backbone (`WBS-03`, complexity XL, risk high) đã ước 52 MD + 18,2 MD dự phòng (35%) = 70,2 MD chỉ để dựng xương sống, trước khi làm bất kỳ nghiệp vụ nào (nguồn: `estimate.computed.json`)
Chi phí 3 năm (sơ bộ, số lượng thành phần — chưa quy đổi VND)	~10 RDS logic + 1 cụm MSK (Kafka) + 1 cụm OpenSearch đa node + ~10 ECS/EKS service group tự động mở rộng riêng — nhiều thành phần phải trả phí/quản lý độc lập nhất trong 3 phương án đã qua gate cứng. 8/8 khoản chi phí non-labor trong hồ sơ thầu đều `amount: null` (`CON-01`) — không có số VND thật để so sánh, chỉ so sánh được số lượng/loại thành phần
Rủi ro chính	(a) Không có bằng chứng team từng vận hành Kafka/MSK, OpenSearch cluster, EKS trong production (`CTX §4.4`); (b) 4 đối tác tích hợp bên ngoài (VNPay/Momo/GHN/GHTK) chưa sandbox thật (`CTX §4.2`, độc lập với lựa chọn kiến trúc nội bộ nhưng số lượng service tăng số điểm tích hợp phải xử lý retry/idempotent riêng lẻ); (c) `WBS (42,48 MM) lệch 54,47% so với UCP (27,5 MM)` — cảnh báo tự động trong `estimate.computed.json.crosscheck` vượt ngưỡng 25%, dấu hiệu ước lượng effort chưa ổn định. (Chưa lập `ARISK-nn` chính thức — thuộc Bước 5, ngoài phạm vi lượt chạy này; ba điểm trên là ứng viên trực tiếp)
Đảo ngược được không, tốn bao nhiêu	Ranh giới service theo domain đã rõ — dễ thay/rút bớt từng service riêng lẻ về sau (ví dụ gộp Review vào Promotion nếu tải thấp) mà không phải viết lại toàn bộ; nhưng gộp ngược lại thành ít service hơn (nếu phát hiện team quá nhỏ để vận hành 10 service) tốn công tái cấu trúc network/DB đáng kể

Sơ đồ mức khối (C4 Context/Container — chỉ hộp lớn, chưa phải component; xem legend §3.3)

flowchart LR
    subgraph P1["P1 — Modular microservices (~10 service, database-per-service)"]
        Client1["Web/Seller/Admin Clients"] -->|"1 · HTTPS REST, sync"| GW1["API Gateway / BFF"]
        GW1 -->|"2 · REST, sync"| SVC1["~10 bounded-context services\n(Identity, Catalog, Search, Cart&Order,\nPayment, Seller, Commission, Promo,\nReview, Notify, Shipping)"]
        SVC1 -->|"3 · publish, async"| MQ1[("Kafka / Amazon MSK")]
        MQ1 -->|"4 · consume, async"| SVC1
        SVC1 -->|"5 · SQL, sync"| DB1[("RDS PostgreSQL Multi-AZ\ndatabase-per-service, ~10 logic DB")]
        SVC1 -->|"6 · cache/session, sync"| CACHE1[("ElastiCache Redis")]
        SVC1 -->|"7 · index/query, sync"| SEARCH1[("OpenSearch, đa node")]
        SVC1 -->|"8 · REST/webhook, sync+async"| EXT1["VNPay · Momo · GHN · GHTK · Email/SMS"]
    end

P2 — Modular monolith + managed AWS services, tách riêng Payment (phương án đối trọng độc lập)


Ý tưởng một câu	Một (hoặc vài) deployable module hoá theo domain, chạy trên ECS Fargate với 2–3 nhóm service thay vì 10, dùng SQS/EventBridge thay Kafka/MSK, tách riêng duy nhất Payment Service để giữ ranh giới PCI-DSS
Thành phần chính	Modular monolith gồm module: Identity, Catalog & Inventory, Cart & Order (+ Dispute), Seller Management, Commission & Payout, Promotion & Loyalty, Review, Notification, Shipping & Fulfillment — chạy trong 2–3 nhóm ECS Fargate service (ví dụ: nhóm "giao dịch" Cart/Order/Catalog tách riêng để scale nhanh hơn nhóm "hỗ trợ" Seller/Promo/Review/Notify/Shipping); Payment Service tách hoàn toàn độc lập (network + IAM riêng) — bắt buộc theo `CON-06`, không phải tuỳ chọn
Mua gì / tự làm gì	Giống P1 về business logic tự xây; khác ở lựa chọn hạ tầng: SQS/EventBridge (không cần cụm Kafka tự quản lý), OpenSearch hoãn dùng managed service đa node ngay từ đầu — dùng Postgres full-text search cho giai đoạn đầu MVP, chuyển sang OpenSearch khi có bằng chứng cần (dựa `DRV-04` số liệu thật sau go-live)
Dữ liệu nằm ở đâu, ai sở hữu	1 RDS PostgreSQL Multi-AZ chính, chia theo schema-per-module (ranh giới logic rõ ràng dù chung instance) — trừ Payment có RDS riêng nhỏ, tách biệt hoàn toàn khỏi cụm chính (không service khác truy cập trực tiếp)
Ai vận hành	Cùng team FTE như P1 (chưa có số thật khác biệt — cả hai phương án dùng chung giả định `DEC-02`), nhưng số đơn vị triển khai cần vận hành/on-call giảm từ ~10 xuống ~3 (2–3 nhóm monolith + 1 Payment Service riêng) — khớp trực tiếp với FTE DevOps trung bình thấp (~0,7 FTE, nguồn giống P1)
Thời gian tới bản chạy được	Không cần hạng mục dựng "event backbone Kafka/MSK" (XL, 35% contingency) như P1 — SQS/EventBridge là managed service dùng ngay, giảm phần lớn effort tương ứng trong `WBS-03`; các hạng mục nghiệp vụ (WBS-18…43) không đổi giữa P1/P2 vì cùng phạm vi FR
Chi phí 3 năm (sơ bộ, số lượng thành phần — chưa quy đổi VND)	1–2 RDS instance (thay vì ~10 logic DB cần theo dõi riêng) + SQS/EventBridge (không có cụm phải patch/scale thủ công như MSK) + Postgres FTS giai đoạn đầu (không cần cụm OpenSearch đa node ngay) + 2–3 ECS service group (thay vì ~10) — ít thành phần quản lý độc lập hơn hẳn P1. Cùng hạn chế: 8/8 khoản non-labor trong hồ sơ thầu `amount: null` — không có số VND thật, chỉ so sánh số lượng/loại thành phần
Rủi ro chính	(a) SQS/EventBridge chưa được đo throughput thật cho tải đỉnh `DRV-04` — `ASM-07`; (b) 1 RDS chính cho nhiều module chưa đo tải ghi/đọc gộp — `ASM-08`; (c) cùng rủi ro đối tác bên ngoài 🔴 như P1 (`CTX §4.2`, không phụ thuộc kiến trúc nội bộ); (d) nếu traffic thật vượt xa dự kiến, tách Catalog/Search ra khỏi monolith muộn sẽ tốn hơn tách từ đầu (đánh đổi đã nêu ở §1). (Chưa lập `ARISK-nn` chính thức — Bước 5)
Đảo ngược được không, tốn bao nhiêu	Module hoá rõ theo domain trong code (namespace/package riêng biệt) giúp tách thành service riêng về sau có kế hoạch khi có bằng chứng tải thật cần (khác gộp ngược từ 10 service như P1) — nhưng tốn công tách hạ tầng (network, DB, CI/CD riêng) tại thời điểm tách, không miễn phí

Sơ đồ mức khối (C4 Context/Container — chỉ hộp lớn; xem legend §3.3)

flowchart LR
    subgraph P2["P2 — Modular monolith + managed AWS, Payment tách riêng"]
        Client2["Web/Seller/Admin Clients"] -->|"1 · HTTPS REST, sync"| GW2["API Gateway / ALB"]
        GW2 -->|"2 · REST, sync"| MONO2["Modular monolith\n(Identity, Catalog, Cart&Order, Seller,\nCommission, Promo, Review, Notify, Shipping)\n2-3 nhóm ECS Fargate"]
        GW2 -->|"2b · REST, sync, cô lập mạng riêng"| PAY2["Payment Service\n(tách bắt buộc — CON-06 PCI-DSS SAQ A)"]
        MONO2 -->|"3 · publish, async"| BUS2[("SQS / EventBridge")]
        PAY2 -->|"3b · publish, async"| BUS2
        BUS2 -->|"4 · consume, async"| MONO2
        MONO2 -->|"5 · SQL, sync"| DB2[("RDS PostgreSQL Multi-AZ\n1 cụm chính, schema-per-module")]
        PAY2 -->|"5b · SQL, sync"| DBPAY2[("RDS riêng, nhỏ — chỉ Payment")]
        MONO2 -->|"6 · cache/session, sync"| CACHE2[("ElastiCache Redis")]
        MONO2 -->|"7 · index/query, sync"| SEARCH2[("Postgres full-text (giai đoạn đầu)\n→ OpenSearch khi có bằng chứng cần")]
        MONO2 -->|"8 · REST/webhook, sync+async"| EXT2["GHN · GHTK · Email/SMS"]
        PAY2 -->|"8b · REST/webhook, sync+async"| EXTPAY2["VNPay · Momo"]
    end

3.3 Legend cho cả hai sơ đồ P1/P2 (bắt buộc theo `D4`)

Số	Loại mũi tên	Giao thức	Sync/Async	Ghi chú
1	Client → Gateway	HTTPS REST	Sync	Người dùng chờ phản hồi
2 / 2b	Gateway → Service	REST (nội bộ)	Sync	2b (P2): Payment nằm sau ranh giới mạng/IAM riêng, không chung network với monolith
3 / 3b	Service → Message bus	Publish event	Async	Domain event (VD `OrderPlaced`)
4	Message bus → Service	Consume event	Async	Xử lý chuỗi sau đặt hàng (hoa hồng, payout, notify, loyalty)
5 / 5b	Service → Database	SQL (JDBC/driver)	Sync	5b (P2): Payment có RDS riêng, không service khác truy cập
6	Service → Cache	Redis protocol	Sync	Session, giỏ hàng, cache đọc
7	Service → Search	Query API	Sync	P1: OpenSearch ngay từ đầu · P2: Postgres FTS giai đoạn đầu
8 / 8b	Service ↔ Đối tác ngoài	REST/webhook (theo `SAD.md §3.4`)	Sync (gọi) + Async (webhook/IPN)	Timeout/retry cụ thể: xem `CTX §4.2`, kế thừa `SAD.md §3.4` — chưa kiểm chứng với sandbox thật (🔴, `CON-04`)

C4 mức: Container (không phải Component) — mỗi hộp là một đơn vị triển khai/nhóm đơn vị triển khai, chưa xuống tới class/module code. Không trộn mức.

4. Bảng chấm điểm

Thang 1–5. Chỉ chấm các phương án đã qua gate cứng §2.1 (P0, P1, P2). P3, P4 bị loại ở §5, không chấm điểm đầy đủ.

Tiêu chí	Trọng số	P0	P1	P2
1. Đáp ứng `DRV` Must	25%	1	5	4
2. Chi phí 3 năm (sơ bộ)	20%	5	2	4
3. Thời gian tới bản chạy được	15%	5	2	4
4. Rủi ro kỹ thuật	15%	5	2	4
5. Năng lực team & vận hành (Conway)	15%	5	2	5
6. Khả năng tiến hoá	10%	1	4	3
Tổng có trọng số	100%	3.60	2.95	4.05

Lý do từng ô

Tiêu chí	P0	P1	P2
1. `DRV` Must	Không xây gì ⇒ vi phạm trực tiếp `DRV-01` (blocker) — điểm sàn	Đáp ứng đầy đủ nhất: scale-out độc lập Catalog/Search khỏi Checkout ngay từ đầu (`DRV-04`), event backbone tách chuỗi hoa hồng/payout khỏi luồng chính (`DRV-06`)	Đáp ứng phần lớn nhưng scale-out Catalog/Search chưa độc lập ở giai đoạn đầu (chung nhóm monolith) — thua P1 đúng một bậc, không giả vờ ngang bằng
2. Chi phí (sơ bộ)	Không phát sinh chi phí hạ tầng	Nhiều thành phần managed độc lập nhất phải vận hành (~10 RDS logic + MSK + OpenSearch đa node + ~10 ECS group) — chi phí vận hành sơ bộ cao nhất trong 2 phương án đã qua gate	Ít thành phần hơn hẳn (1–2 RDS + SQS/EventBridge + Postgres FTS + 2–3 ECS group) — chi phí vận hành sơ bộ thấp hơn P1
3. Thời gian	Có ngay, 0 effort	`WBS-03` (dựng nền tảng dịch vụ & event backbone) một mình đã 70,2 MD (XL, +35% contingency) trước khi làm nghiệp vụ	Không cần dựng cụm Kafka/MSK — dùng managed service có sẵn ngay, effort nền tảng thấp hơn đáng kể so với P1
4. Rủi ro kỹ thuật	Không có rủi ro kỹ thuật (không xây)	Không có bằng chứng team từng vận hành Kafka/MSK, OpenSearch, EKS production (`CTX §4.4`); cảnh báo lệch WBS↔UCP 54,47% (`estimate.computed.json.crosscheck`)	Công nghệ managed phổ biến hơn (RDS, SQS/EventBridge, ECS Fargate) — rủi ro "công nghệ mới" thấp hơn; rủi ro đối tác bên ngoài 🔴 giữ nguyên như P1 (không đổi bởi kiến trúc nội bộ)
5. Năng lực team (Conway)	Không cần team	~10 service độc lập trong khi FTE BE trung bình toàn dự án chỉ ~18,31 MM/~7 tháng ≈ 2,6 FTE trung bình (`estimate.computed.json.mmByRole.BE`) — mỗi kỹ sư BE ôm trung bình 3–4 service, vi phạm Conway rõ theo `DEC-02`	Số đơn vị triển khai cần vận hành giảm còn ~3 (2–3 nhóm monolith + Payment) — khớp với cùng FTE BE ~2,6 trung bình tốt hơn P1
6. Khả năng tiến hoá	Giữ nguyên = không tiến hoá được, mỗi ngày trì hoãn là một ngày mất cơ hội thị trường không thu hồi được	Ranh giới service đã tách sẵn — dễ thay/rút từng service riêng lẻ về sau	Module hoá trong code dễ tách dần khi có bằng chứng tải thật, nhưng tách hạ tầng lúc đó tốn công hơn P1 (đã tách sẵn) — thua P1 đúng ở tiêu chí này

🔴 Điểm tổng P1 (2.95) và P2 (4.05) chênh 1.10 — đủ phân biệt, không rơi vào bẫy "chênh <0.3". P0 (3.60) và P2 (4.05) chênh 0.45 — cũng đủ phân biệt, nhưng nhắc lại: P0 vi phạm DRV-01 (Must, blocker) nên dù điểm tổng gần P2, P0 không phải lựa chọn khả thi — đây là lý do điểm P0 cao ở nhiều tiêu chí "chi phí/thời gian/rủi ro" (vì không làm gì thì các tiêu chí đó tự nhiên thấp) nhưng lại thua tuyệt đối ở tiêu chí có trọng số cao nhất (Đáp ứng DRV Must, 25%).

5. Phương án bị loại và lý do (bắt buộc — quy tắc `D3`)

Phương án	Đã cân nhắc vì	Loại vì	Gắn với	Điều kiện nào thì xét lại
P3 — Mua/tích hợp nền tảng multi-vendor mã nguồn mở (VD Medusa.js, Bagisto) + tuỳ biến tách đơn đa seller, hoa hồng/payout, KYC seller	Có thể giảm effort xây lõi catalog/cart/order từ đầu, tăng tốc thời gian ra bản chạy được — đúng như gợi ý cân nhắc trong ghi chú người duyệt	(a) Không có bằng chứng nền tảng ứng viên nào hỗ trợ sẵn mô hình hold 3–7 ngày + audit trail tài chính riêng theo đúng `DRV-06`/FR-21/22 — phải sửa lõi sâu, mất lợi thế "mua sẵn"; (b) không kiểm chứng được cô lập Payment Service cho PCI-DSS SAQ A nếu không sửa sâu lõi nền tảng — vi phạm `CON-06` (gate cứng §2.1); (c) chưa có bằng chứng năng lực team với stack cụ thể của nền tảng này (PHP/Laravel hay Node tuỳ nền tảng) — `ASM` mới, không phải số liệu đã có	`CON-06` (loại cứng), `CON-05` (rủi ro năng lực)	Nếu Tech Lead xác nhận có kinh nghiệm sâu với một nền tảng cụ thể và nền tảng đó chứng minh được (qua POC) khả năng cô lập Payment đúng yêu cầu SAQ A mà không sửa lõi — xét lại cho các module không nhạy cảm tài chính (VD Catalog/Review)
P4 — Serverless-first (Lambda + API Gateway + Step Functions + DynamoDB/Aurora Serverless, EventBridge cho toàn bộ luồng, không container)	Chi phí theo request, không cần quản lý cluster, scale tự động cho flash sale — đúng gợi ý cân nhắc trong ghi chú người duyệt	(a) Cold-start của Lambda cho luồng checkout đồng bộ có nguy cơ ảnh hưởng trải nghiệm ở đúng bước `DRV-02` (bỏ giỏ) — chưa có POC đo cold-start trong ngữ cảnh VPC + kết nối RDS; (b) chưa có bằng chứng năng lực team với serverless-at-scale (`CON-05`); (c) mô hình chi phí theo request khó ước lượng ở quy mô "hàng nghìn–chục nghìn concurrent user" (`DRV-04`) mà không có bài đo — rủi ro hoá đơn tăng phi tuyến (nguồn rủi ro "Chi phí", `SKILL.md` Bước 5)	`DRV-02`, `CON-05`	Nếu có POC đo cold-start đạt yêu cầu checkout và Tech Lead xác nhận năng lực serverless-at-scale — xét lại cho các luồng bất đồng bộ thuần (VD Notification, Commission batch) như một lựa chọn lai với P2, không nhất thiết toàn bộ hệ thống

"Team quen công nghệ X" là lý do hợp lệ — ở đây áp dụng ngược: P3/P4 bị loại một phần vì chưa có bằng chứng team quen (ASM mới), không phải vì SA không thích công nghệ đó.

6. Bảng đánh đổi trình PO

Dịch lựa chọn kỹ thuật thành ngôn ngữ PO hiểu được — so sánh P1 và P2 (P0 đã loại ở §4 vì vi phạm DRV-01).

Nếu chọn	Được	Mất	Tiền chênh 3 năm	Thời gian chênh
P1 (giữ theo `SAD.md`/hồ sơ thầu)	Scale-out độc lập Catalog/Search khỏi Checkout ngay từ đầu; không cần thiết kế lại nếu traffic tăng nhanh hơn dự kiến	Rủi ro Conway cao với team hiện tại (mỗi BE ôm 3–4 service); effort dựng nền tảng lớn hơn; nhiều thành phần managed phải vận hành hơn (MSK, OpenSearch đa node)	Chưa quy đổi VND (`TCO` Bước 5) — sơ bộ cao hơn P2 vì số lượng managed component nhiều hơn (8/8 khoản non-labor hồ sơ thầu đều chưa có số, không thể so tuyệt đối)	+70,2 MD riêng cho nền tảng event backbone (`WBS-03`) so với P2 không cần cụm Kafka/MSK riêng
P2 (khuyến nghị SA)	Khớp Conway với team giả định `DEC-02`; thời gian tới bản chạy được nhanh hơn; ít managed component phải vận hành hơn	Scale-out độc lập Catalog/Search kém hơn ngay từ đầu — có thể phải tách service khi traffic thật vượt ngưỡng, tốn chi phí tái cấu trúc lúc đó (không miễn phí, không định lượng được ở lượt này)	Chưa quy đổi VND — sơ bộ thấp hơn P1	-70,2 MD so với P1 ở riêng hạng mục nền tảng; effort nghiệp vụ (WBS-18…43) không đổi giữa hai phương án

7. Cắt gì thì giảm bao nhiêu

Chưa áp dụng ở lượt chạy này. TCO bằng VND thật (Bước 5) chưa tồn tại, và CON-01 (ngân sách) vẫn "Chưa xác định" (OQ-005 còn mở) — không có số ngân sách đã duyệt để đối chiếu và đề xuất cắt giảm có ý nghĩa. Mục này sẽ điền khi TCO (Bước 5) hoàn thành và OQ-005 có câu trả lời bằng số thật.

8. Giả định & Ngoài phạm vi

Giả định — ASM-nn ảnh hưởng tới lựa chọn này (tiếp số từ CTX §5, bắt đầu ASM-07):

ID	Giả định	Nếu sai thì phương án nào đổi
`ASM-07`	Amazon SQS/EventBridge (không phải Kafka/MSK) đủ đáp ứng thông lượng cho luồng `OrderPlaced`/`PaymentConfirmed` ở tải đỉnh flash sale (`DRV-04`, "hàng nghìn–chục nghìn concurrent user") — chưa có POC đo throughput thật trong ngữ cảnh này. Cách xác minh: POC đo SQS FIFO/EventBridge với payload tương tự `OrderPlaced` ở tải giả lập tương ứng `DRV-04`. Chủ: Tech Lead. Hạn: trước khi chốt `ADR` message backbone ở GĐ2	Nếu sai (không đủ throughput): P2 phải bổ sung Kafka/MSK riêng cho hot-path đặt hàng (kiến trúc lai P1+P2 cho riêng luồng này), không chuyển hẳn sang P1 vì phần còn lại của P1 vẫn vi phạm Conway
`ASM-08`	1 cụm RDS PostgreSQL Multi-AZ chính (schema-per-module) đủ chịu tải ghi/đọc gộp cho toàn bộ module ngoại trừ Payment tách riêng — chưa đo. Cách xác minh: POC load test theo kịch bản `NFR-01`/`NFR-02`. Chủ: Tech Lead/DBA. Hạn: trước GĐ2 (`DAT`)	Nếu sai: phải tách read replica/DB riêng cho Catalog/Search sớm hơn dự kiến trong P2, tăng chi phí vận hành tiệm cận P1 cho phần đó
`ASM-09`	Bộ tiêu chí và trọng số ở §2.2 (mặc định từ template, chưa qua buổi duyệt riêng với PO/Tech Lead) phản ánh đúng ưu tiên thật của dự án — xem cảnh báo cuối §2.2	Nếu PO tăng mạnh trọng số "Đáp ứng `DRV` Must", thứ hạng P1/P2 có thể đổi (P1 mạnh nhất ở tiêu chí này) — xem `OQ-011`

Giả định ASM-01…06 của CTX (ngân sách, deadline, đội vận hành, residency, dùng SAD.md làm điểm khởi đầu, hoá đơn điện tử hoãn) vẫn áp dụng nguyên trạng cho toàn bộ OPT — không lặp lại nội dung ở đây, chỉ tham chiếu.

Ngoài phạm vi:

TCO bằng VND thật, 3 năm, ≥2 kịch bản tải — thuộc Bước 5, chưa làm ở lượt chạy này. Mọi con số "chi phí" trong tài liệu này là số lượng/loại thành phần hạ tầng để so sánh tương đối, không phải tiền.
ARISK (sổ rủi ro kiến trúc chính thức) và kế hoạch POC có tiêu chí pass/fail viết trước — thuộc Bước 5, chưa lập. ASM-07/ASM-08 ở trên là ứng viên trực tiếp để nâng thành ARISK-nn khi Bước 5 chạy.
Thiết kế chi tiết ranh giới service/module (contract cụ thể, tên bảng, tên topic/queue) — thuộc GĐ2 (SAD, ADR), không được vẽ ở đây dù đã có gợi ý từ SAD.md/hồ sơ thầu.
Quyết định cuối cùng chọn P1 hay P2 (hay phương án lai) — đây là khuyến nghị của SA, chưa phải quyết định; quyết định thật cần PO + Tech Lead ký (OQ-011).
Đối chiếu chi tiết với OQ-003 (giữ toàn sàn hay thu hẹp phạm vi) — cả ba phương án ở đây mô tả kiến trúc tổng thể toàn sàn theo phạm vi đã chốt của lượt chạy này; nếu OQ-003 sau này quyết định thu hẹp, bảng chấm điểm có thể cần chấm lại với phạm vi hẹp hơn.

9. 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-010`	Tech Lead xác nhận: đội thi công thật (không phải đề xuất trong hồ sơ thầu) có kinh nghiệm vận hành production nào với Kafka/MSK, OpenSearch cluster, EKS chưa? Đây là input trực tiếp cho tiêu chí "Rủi ro kỹ thuật" đã chấm P1=2/P2=4 ở §4.	Tech Lead	2026-09-12	Điểm "Rủi ro kỹ thuật" của P1 trong `OPT`; `ARISK` Bước 5	Nếu đội thật có kinh nghiệm Kafka/MSK/OpenSearch/EKS production: nâng điểm rủi ro kỹ thuật P1 lên 3–4, thu hẹp khoảng cách điểm tổng với P2 (từ 1.10 xuống có thể ~0.4–0.7) — vẫn cần xem lại tiêu chí "Năng lực team & vận hành" (Conway) vì đó không phụ thuộc kinh nghiệm công nghệ mà phụ thuộc số người so với số service
`OQ-011`	PO + Tech Lead chọn phương án nào giữa P1 (theo `SAD.md`/hồ sơ thầu hiện có) và P2 (khuyến nghị SA), hay yêu cầu SA dựng thêm phương án lai (VD P2 nhưng tách Catalog/Search từ đầu)? Đây chính là nội dung cần ký ở AG1 cho `OPT`.	PO + Tech Lead	2026-09-12	Ký AG1 cho `OPT`; bắt đầu Bước 5 (`TCO`/`ARISK`) theo đúng phương án đã chọn	Nếu chọn P1 dù rủi ro Conway cao: phải tăng team BE thật lên gần mức bid đề xuất (đỉnh điểm 10 người, chủ yếu BE) hoặc giảm số service xuống dưới 10 trước khi GĐ2 chốt ranh giới — nếu không, ranh giới service ở `SAD` GĐ2 sẽ vi phạm Conway ngay từ thiết kế, phát hiện muộn hơn và tốn hơn theo đúng cảnh báo của `GUIDE.md`
`OQ-012`	Có cần chạy POC đo throughput SQS/EventBridge (`ASM-07`) trước khi chốt P2 làm phương án chính thức, hay chấp nhận rủi ro tạm thời và bổ sung `ARISK` + kế hoạch POC ở Bước 5 rồi mới đo?	Tech Lead	2026-09-12	`ADR` message backbone ở GĐ2; kế hoạch POC ở `ARISK` Bước 5	Nếu không đo trước khi chốt `ADR` GĐ2 mà đo sau mới phát hiện SQS/EventBridge không đủ throughput: phải viết lại `ADR` (Supersede) sau khi đã thiết kế chi tiết — tốn hơn phát hiện ở GĐ1 theo đúng nguyên tắc `workflow.md §6` "GĐ2 → GĐ1"

Tự chấm

① Bảng tự chấm Gate AG1 (`workflow.md §2`, cập nhật từ `CTX`)

#	Tiêu chí	☐/✅	Ghi chú
1	`CTX` có `DRV-nn`, mỗi driver ghi rõ áp lực kinh doanh	✅	Không đổi — xem `CTX §2`
2	`CTX` có `CON-nn` (ràng buộc 6 nhóm)	✅ (với lưu ý)	Không đổi — xem `CTX §3`
3	`CTX` mô tả hiện trạng as-is	✅ (với lưu ý)	Không đổi — xem `CTX §4`
4	`OPT` có ≥2 phương án được chấm điểm, nêu rõ phương án bị loại + lý do	✅	Mới đạt ở lượt này — 3 phương án chấm điểm (P0, P1, P2) + 2 phương án bị loại có lý do gắn `CON`/`DRV` cụ thể (P3, P4). Trọng số tiêu chí chưa qua buổi duyệt riêng với PO/Tech Lead (`ASM-09`) — đây là hạn chế cần ghi nhận, không phải lý do đánh rớt tiêu chí này (tiêu chí AG1 chỉ đòi hỏi "có ≥2 phương án chấm điểm + nêu loại", không đòi hỏi trọng số đã duyệt)
5	`TCO` có chi phí 3 năm, ≥2 kịch bản tải	☐	Chưa tạo file `TCO` — thuộc Bước 5, ngoài phạm vi lượt chạy này. `OPT` chỉ so sánh số lượng/loại thành phần hạ tầng, không phải VND
6	`ARISK` có rủi ro cao kèm chủ + biện pháp	☐	Chưa tạo file `ARISK` — thuộc Bước 5. `ASM-07`/`ASM-08` ở §8 là ứng viên trực tiếp để nâng thành `ARISK-nn`
7	Rủi ro cao chưa chứng minh được có kế hoạch POC	☐	Phụ thuộc `ARISK`, chưa làm. `OQ-012` đã đặt câu hỏi về thời điểm chạy POC SQS/EventBridge

Kết luận tự chấm AG1: Vẫn chưa đủ điều kiện ký — 4/7 tiêu chí ✅ (tăng từ 3/7 ở CTX). Cần Bước 5 (TCO, ARISK + kế hoạch POC) trước khi PO + Tech Lead có thể ký AG1 đầy đủ. Ngay cả khi ký AG1 chỉ dựa trên OPT này, khuyến nghị không ký cho tới khi OQ-005/OQ-006/ OQ-008/OQ-010/OQ-011 có câu trả lời vì bảng chấm điểm ở đây dùng số liệu tham khảo hồ sơ thầu (Draft), không phải số đã xác nhận.

② 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 tạo `ADR` — quyết định kiến trúc chính thức (nếu có) sẽ thành `ADR` ở GĐ2 sau khi P1/P2 được PO/Tech Lead chọn
D2	Không NFR định tính	N/A	`OPT` không chứa `QAS`; các con số hạ tầng dùng nguồn cụ thể (`estimate.computed.json`), không phải mô tả định tính
D3	Nêu phương án bị loại + lý do gắn `CON`/`QAS`	✅	§5 — P3 loại vì `CON-06` (gate cứng); P4 loại vì `DRV-02`/`CON-05` (rủi ro + thiếu bằng chứng năng lực). Cả hai đều có điều kiện xét lại rõ ràng, không phải loại vĩnh viễn theo cảm tính
D4	Sơ đồ khai báo mức C4 + legend	✅	P1/P2 đều khai báo "C4 mức Container", có bảng legend chung §3.3 giải thích từng loại mũi tên + sync/async
D5	Interface có chủ/contract	N/A	Chưa tới `ICD` (GĐ2) — §3.4 `SAD.md` chỉ kế thừa nguyên trạng đề xuất, ghi rõ chưa xác minh sandbox thật (`CON-04`)
D6	Phụ thuộc ngoài process có timeout/retry	N/A	Chưa tới `FAIL` (GĐ2); bảng legend §3.3 dòng 8/8b dẫn về `CTX §4.2`/`SAD.md §3.4` cho chi tiết timeout/retry hiện có (đề xuất, chưa kiểm chứng)
D7	Một chủ sở hữu dữ liệu	✅ (ở mức khối)	Cả P1 và P2 đều ghi rõ Payment có DB riêng, không service/module khác truy cập trực tiếp — chi tiết từng thực thể để `DAT` (GĐ2)
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	Mọi con số hạ tầng ở đây có nguồn (`estimate.computed.json`, `SAD.md §3.1-3.4`) nhưng chưa quy ra tiền — đúng theo yêu cầu "chỉ mức sơ bộ để so sánh tương đối" của ghi chú người duyệt; quy đổi VND đầy đủ + khớp `TCO`/`INF` là việc của Bước 5/GĐ2
D10	Không quyết định thay người có thẩm quyền	✅	§1 ghi rõ "khuyến nghị… chưa phải quyết định"; mọi lựa chọn cuối (P1 vs P2, trọng số tiêu chí, thời điểm chạy POC) đều để `OQ-010/011/012` kèm hệ quả phương án ngược bằng số/định tính cụ thể, không tự quyết
D11	Có mục "Ngoài phạm vi" + `ASM-nn`	✅	§8 đầy đủ — `ASM-07/08/09` mới, có cách xác minh/chủ/hạn; mục "Ngoài phạm vi" liệt kê rõ `TCO`/`ARISK`/thiết kế chi tiết GĐ2/quyết định cuối cùng đều chưa làm
D12	Câu quy định thẩm quyền sơ đồ vs văn bản	✅	Có ngay sau Change Log

③ Danh sách `OQ` mở kèm người phải trả lời, chặn gì

Ba câu hỏi mới của OPT (OQ-010, OQ-011, OQ-012) cộng với các câu hỏi còn mở từ CTX (OQ-001, OQ-002 (đã đóng, xem CTX), OQ-003, OQ-004, OQ-005, OQ-006, OQ-007, OQ-008) — xem sổ đầy đủ tại 00-index/OQ_e-commerce.md (đã đồng bộ ở Change Log v1.5). Ba câu quan trọng nhất cho việc ký AG1 của chính OPT này: OQ-011 (chọn P1/P2 — chặn ký AG1 trực tiếp), OQ-010 (kinh nghiệm team thật — chặn độ tin cậy điểm "Rủi ro kỹ thuật"), OQ-005/OQ-006/OQ-008 (ngân sách/deadline/team thật — chặn TCO/ARISK Bước 5 có ý nghĩa).

Nhắc: AG1 cần PO + Tech Lead ký (điền Approved by vào header file này) trước khi chạy /sa-2-architecture. Cần chạy tiếp Bước 5 (TCO, ARISK) của sa-1-context trước khi bảng tự chấm AG1 đạt đủ 7/7 tiêu chí.

48 KiB Raw Permalink Blame History Unescape Escape