369 lines
48 KiB
Markdown
369 lines
48 KiB
Markdown
# 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)*
|
||
|
||
```mermaid
|
||
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)*
|
||
|
||
```mermaid
|
||
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í.
|