178 lines
12 KiB
Markdown
178 lines
12 KiB
Markdown
# ADR-012 — Ranh giới nhóm triển khai (deployment boundary): Nhóm Giao dịch / Nhóm Hỗ trợ / Payment tách biệt
|
||
|
||
*Tên file: `adr/ADR-012_ranh-gioi-nhom-trien-khai-theo-domain.md`*
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Status** | `Proposed` |
|
||
| **Date** | 2026-09-15 |
|
||
| **Người quyết** | SA + Tech Lead (cấu trúc/ranh giới service — `decision-radar.md §5`) |
|
||
| **Người đề xuất** | SA (qua skill `sa-2-architecture`, hoạt động `adr`) |
|
||
| **Điểm radar** | **~7/10** |
|
||
| **Supersedes** | — |
|
||
| **Superseded by** | — |
|
||
| **Liên quan** | `ASR-014` · `CON-05` · `OQ-010` · `OQ-026` · `ASM-19` · `ASM-22` · `ASM-23` · `ADR-001` · `SAD §4.1, §7` |
|
||
|
||
> ⚠️ **ADR bất biến sau khi `Accepted`.** Muốn đổi quyết định thì viết ADR mới có
|
||
> `Supersedes: ADR-012` và đổi trạng thái bản cũ thành `Superseded by`.
|
||
|
||
---
|
||
|
||
## 1. Bối cảnh
|
||
|
||
`ADR-001` đã chọn modular monolith (P2) với 2–3 nhóm triển khai ECS Fargate thay vì ~10 service
|
||
độc lập. ADR này là **quyết định cụ thể tiếp theo**: module nào nằm nhóm nào — khác `ADR-001` ở
|
||
chỗ đó là quyết định "monolith hay không", còn đây là "ranh giới cụ thể bên trong monolith".
|
||
`ASR-014` ghi nhận việc gom module vào nhóm phải phản ánh đúng năng lực đội thi công **thật**,
|
||
không chỉ theo giả định "team MVP chuẩn" (`DEC-02`). Hai câu hỏi mở trực tiếp ảnh hưởng ADR này:
|
||
`OQ-010` (số đội thi công thật) và `OQ-026` (SAD phát hiện lệch mức chi tiết giữa "2 nhóm ECS
|
||
service riêng" và cách `TCO §3.2` tính gộp compute thành 1 dòng).
|
||
|
||
**Ràng buộc đang chi phối:**
|
||
|
||
| Nguồn | Nội dung |
|
||
|---|---|
|
||
| `ASR-014` | Ranh giới nhóm triển khai phải khớp năng lực đội thi công thật |
|
||
| `CON-05` | Team giả định "team MVP chuẩn" (`DEC-02`), chưa xác nhận thật |
|
||
| `OQ-010` | Tech Lead chưa xác nhận đội thi công thật |
|
||
| `OQ-026` | `TCO §3.2` tính gộp compute — chưa rõ là 1 hay 2 ECS service thật |
|
||
| `ASM-22` | Identity & Access xếp vào Nhóm Giao dịch — suy luận từ `ASR-010`/`011`, chưa Tech Lead xác nhận |
|
||
|
||
**Cái đã biết chắc / cái còn là giả định:**
|
||
|
||
| Điều | 🟢 Đã kiểm chứng / 🔴 Giả định | Bằng chứng |
|
||
|---|---|---|
|
||
| Payment phải tách biệt hoàn toàn khỏi 2 nhóm còn lại | 🟢 Đã kiểm chứng | `ADR-002` (độc lập với ADR này) |
|
||
| Nhóm Giao dịch (Catalog & Inventory, Cart & Order) cần scale nhanh hơn Nhóm Hỗ trợ | 🟡 Ước lượng có cơ sở | `DRV-04`, `OPT §3` — chưa có số đo thật sau go-live |
|
||
| Identity & Access thuộc Nhóm Giao dịch (không phải nhóm riêng/Nhóm Hỗ trợ) | 🔴 Giả định (`ASM-22`) | Suy từ `ASR-010`/`011` ("nhóm giao dịch cốt lõi" bao gồm Identity cho HA/DR) — `OPT §3` không nói rõ |
|
||
| `TCO §3.2` phản ánh đúng 2 ECS service riêng (không phải 1 service gộp) | 🔴 Giả định (`ASM-23`) | `OQ-026` — chưa Tech Lead/Ops xác nhận |
|
||
|
||
## 2. Phương án đã cân nhắc
|
||
|
||
### PA-1 — 1 nhóm ECS duy nhất cho toàn bộ monolith (không tách Nhóm Giao dịch/Nhóm Hỗ trợ)
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Mô tả** | Toàn bộ 9 module (trừ Payment) chạy trong 1 ECS Fargate service duy nhất, scale chung |
|
||
| **Ưu** | Đơn giản nhất — chỉ 2 đơn vị triển khai (1 monolith + 1 Payment); ít cấu hình network/scaling riêng |
|
||
| **Nhược** | Không thể scale-out riêng Catalog/Cart&Order khi flash sale mà không kéo theo cả Nhóm Hỗ trợ — lãng phí tài nguyên hoặc thiếu tài nguyên đúng lúc cần; vi phạm `DRV-04` một phần (mục tiêu chịu tải đỉnh của riêng luồng giao dịch) |
|
||
| **Chi phí đảo ngược** | Trung bình — tách thành 2 nhóm sau này cần cấu hình lại network/scaling policy, nhưng không cần migrate dữ liệu (cùng schema-per-module) |
|
||
|
||
### PA-2 — 2 nhóm ECS: Nhóm Giao dịch (Identity, Catalog, Cart&Order) / Nhóm Hỗ trợ (còn lại) *(chọn tạm)*
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Mô tả** | Theo `OPT §3` P2 — Nhóm Giao dịch gồm Identity & Access, Catalog & Inventory, Cart & Order; Nhóm Hỗ trợ gồm Seller Management, Commission & Payout, Promotion & Loyalty, Review, Notification, Shipping & Fulfillment; mỗi nhóm là 1 ECS Fargate service riêng, scale độc lập |
|
||
| **Ưu** | Cho phép scale riêng Nhóm Giao dịch khi flash sale mà không ảnh hưởng Nhóm Hỗ trợ (đáp ứng `DRV-04`); khớp đề xuất đã duyệt từng phần ở `OPT §3`/`DEC-06` |
|
||
| **Nhược** | Vị trí Identity & Access trong Nhóm Giao dịch là **suy luận của SA** (`ASM-22`), chưa được Tech Lead xác nhận trực tiếp; `OQ-026` cho thấy `TCO` chưa rõ có tính đúng 2 service riêng hay không — nếu `TCO` thực ra tính 1 service, phương án này phát sinh chi phí chưa được duyệt |
|
||
| **Chi phí đảo ngược** | Trung bình — đổi thành viên giữa 2 nhóm (VD chuyển Identity sang Nhóm Hỗ trợ) là thay đổi cấu hình + CI/CD, không phải viết lại code (nhờ ranh giới module đã có ở `ADR-001`) |
|
||
|
||
### PA-3 — 3 nhóm ECS: tách riêng Identity & Access thành nhóm thứ ba (ngoài Nhóm Giao dịch/Nhóm Hỗ trợ)
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Mô tả** | Identity & Access là một ECS service riêng biệt, không thuộc Nhóm Giao dịch hay Nhóm Hỗ trợ, vì đây là dịch vụ nền tảng được cả hai nhóm gọi tới |
|
||
| **Ưu** | Tách bạch rõ ràng vai trò "hạ tầng xác thực dùng chung" khỏi logic nghiệp vụ Catalog/Cart&Order; có thể scale/HA riêng cho Identity mà không phụ thuộc tải của Catalog |
|
||
| **Nhược** | Thêm một đơn vị triển khai thứ 4 (ngoài Payment) — tăng chi phí vận hành so với PA-2; chưa có trong ước lượng `TCO §3.2` nào (chỉ có "monolith" + Payment) |
|
||
| **Chi phí đảo ngược** | Thấp — tách Identity ra là thu hẹp phạm vi 1 service, ít rủi ro hơn gộp lại |
|
||
|
||
### Bảng so sánh
|
||
|
||
| Tiêu chí | PA-1 (1 nhóm) | PA-2 (2 nhóm, Identity ở Nhóm Giao dịch) | PA-3 (3 nhóm, Identity riêng) |
|
||
|---|---|---|---|
|
||
| Scale riêng Nhóm Giao dịch khi flash sale (`DRV-04`) | ❌ | ✅ | ✅ |
|
||
| Khớp `OPT §3`/`DEC-06` đã duyệt từng phần | ❌ | ✅ | 🔶 Gần khớp, thêm 1 nhóm |
|
||
| Khớp `TCO §3.2` hiện tại (chưa rõ, `OQ-026`) | ✅ (nếu TCO tính 1 service) | 🔶 Chờ xác nhận | ❌ Chưa có trong TCO |
|
||
| Số đơn vị triển khai | 2 | 3 | 4 |
|
||
|
||
## 3. Quyết định
|
||
|
||
> **Đề xuất PA-2 — 2 nhóm ECS: Nhóm Giao dịch (Identity & Access, Catalog & Inventory, Cart &
|
||
> Order) / Nhóm Hỗ trợ (5 module còn lại), cộng Payment tách biệt.**
|
||
|
||
🔴 **Đây là quyết định tạm, chưa đủ điều kiện `Accepted`** — theo `ASM-22`/`ASM-23` và `OQ-010`/
|
||
`OQ-026` vẫn mở. Giữ PA-2 làm hướng đi (nhất quán với `OPT §3`/`DEC-06`/`SAD §4.1`) cho tới khi
|
||
Tech Lead/Ops xác nhận.
|
||
|
||
**Vì sao đề xuất PA-2:** Cân bằng giữa khả năng scale riêng Nhóm Giao dịch (`DRV-04`, loại PA-1)
|
||
và không phát sinh thêm chi phí vận hành chưa có trong `TCO` (loại PA-3, chờ xác nhận thêm ngân
|
||
sách nếu cần).
|
||
|
||
**Phạm vi áp dụng:** Toàn bộ 9 module ngoài Payment.
|
||
|
||
### Điều kiện chuyển `Proposed → Accepted`
|
||
|
||
| Điều kiện | Ai xác nhận | Trạng thái hiện tại |
|
||
|---|---|---|
|
||
| `OQ-010` — Tech Lead xác nhận số đội thật khớp (hoặc đủ để vận hành) 2–3 nhóm triển khai | Tech Lead | Mở |
|
||
| `OQ-026` — Tech Lead/Ops xác nhận `TCO §3.2` tính đúng 2 ECS service riêng (không phải 1 gộp) | Tech Lead + Ops/SRE | Mở |
|
||
| `OQ-027` — Tech Lead xác nhận vị trí Identity & Access (Nhóm Giao dịch hay riêng/Nhóm Hỗ trợ) | Tech Lead | Mở |
|
||
|
||
## 4. Phương án bị loại và lý do
|
||
|
||
| Phương án | Loại vì | Gắn với | Điều kiện nào thì xét lại |
|
||
|---|---|---|---|
|
||
| PA-1 — 1 nhóm ECS duy nhất | Không đáp ứng nhu cầu scale riêng Nhóm Giao dịch khi flash sale | `DRV-04` | Nếu `OQ-026` xác nhận `TCO` thực ra chỉ tính 1 service (không đủ ngân sách cho 2 nhóm riêng) — quay lại PA-1 và ghi nhận giảm điểm tiêu chí "Đáp ứng DRV Must" đã chấm ở `OPT §4` |
|
||
| PA-3 — 3 nhóm, Identity riêng | Chưa có trong `TCO §3.2`, tăng chi phí vận hành chưa được PO duyệt | `TCO §3.2`, `CON-01` | Nếu Tech Lead xác nhận Identity cần HA/scale độc lập khỏi Catalog/Cart&Order (VD do tải xác thực rất khác biệt) **và** PO duyệt thêm chi phí — trình bảng đánh đổi |
|
||
|
||
## 5. Hệ quả
|
||
|
||
**Hệ quả tích cực**
|
||
|
||
- Cho phép scale riêng Nhóm Giao dịch khi flash sale mà không lãng phí tài nguyên cho Nhóm Hỗ trợ
|
||
- Nhất quán với hướng đi đã duyệt từng phần ở `OPT §3`/`DEC-06`
|
||
|
||
**Hệ quả tiêu cực phải sống chung**
|
||
|
||
- Vị trí Identity & Access vẫn là giả định (`ASM-22`) — rủi ro phải đổi cấu hình khi Tech Lead xác
|
||
nhận khác
|
||
- Nếu `OQ-026` xác nhận `TCO` chưa tính đủ chi phí 2 service riêng, cần cập nhật `TCO` trước khi
|
||
ADR này có thể `Accepted`
|
||
|
||
**Cái quyết định này khoá lại**
|
||
|
||
| Muốn đổi về sau thì | Tốn |
|
||
|---|---|
|
||
| Đổi thành viên giữa Nhóm Giao dịch/Nhóm Hỗ trợ sau khi team đã quen vận hành theo ranh giới cũ | Tái tổ chức CI/CD + on-call — ước 1-3 tuần tuỳ mức độ đổi |
|
||
|
||
**Việc phát sinh**
|
||
|
||
| Việc | Chủ | Hạn | Ghi ở đâu |
|
||
|---|---|---|---|
|
||
| Tech Lead xác nhận `OQ-010` (số đội thật) | Tech Lead | Trước khi `Accepted` | `00-index/OQ_e-commerce.md` |
|
||
| Tech Lead/Ops xác nhận `OQ-026` (khớp TCO) | Tech Lead + Ops/SRE | Trước khi `Accepted`, trước hoạt động `inf` chốt | `00-index/OQ_e-commerce.md` |
|
||
| Tech Lead xác nhận `OQ-027` (vị trí Identity) | Tech Lead | Trước khi `Accepted` | `00-index/OQ_e-commerce.md` |
|
||
|
||
## 6. Cách kiểm chứng quyết định này được tuân thủ
|
||
|
||
| Cách kiểm | Công cụ | Chạy ở đâu | `FIT` |
|
||
|---|---|---|---|
|
||
| Đúng 2 ECS Fargate service (Nhóm Giao dịch, Nhóm Hỗ trợ) + 1 Payment tồn tại trong hạ tầng | Kiểm tra hạ tầng (Terraform plan review) | CI/CD | `FIT-16` (ứng viên) |
|
||
| Module thuộc đúng nhóm theo bảng `CMP-nn` cột "Nhóm triển khai" (`SAD §4.1`) | Review kiến trúc định kỳ | GĐ3 (`DREV`) | — |
|
||
|
||
## 7. Điều kiện xét lại
|
||
|
||
| Dấu hiệu | Ngưỡng | Ai theo dõi |
|
||
|---|---|---|
|
||
| `OQ-010` trả lời team thật khác biệt đáng kể so với giả định | Số BE thật < 50% hoặc > gấp đôi giả định `DEC-02` | Tech Lead |
|
||
| `OQ-026` xác nhận `TCO` chỉ tính 1 service (không đủ ngân sách 2 nhóm) | Khi có xác nhận | PO/Tech Lead |
|
||
| Tải thật cho thấy Identity cần scale độc lập khỏi Catalog/Cart&Order | Dữ liệu production sau go-live | SRE |
|
||
|
||
## 8. Tham chiếu
|
||
|
||
- POC: Không áp dụng
|
||
- Bài đo: `FIT-16` (ứng viên GĐ3)
|
||
- Tài liệu ngoài: `OPT_e-commerce_v1.0.md §3` (P2), `SAD_e-commerce_v1.0.md §4.1, §7, §10 (ASM-22/23), §11 (OQ-026/027)`
|
||
- Thảo luận: `ASR_e-commerce_v1.0.md §B2 ASR-014`
|
||
|
||
## 9. Review log (không đổi Status)
|
||
|
||
| Ngày | Người review | Vai trò | Quyết định | Lý do chưa chuyển `Accepted` |
|
||
|---|---|---|---|---|
|
||
| 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, chế độ chạy thử) | Tech Lead (ký thay, ngoại lệ `DEC-01`) | `Reviewed (Proposed giữ nguyên)` — nội dung đủ làm cơ sở thiết kế tiếp (`icd`/`dat`/`sec`/`inf`/`fail`) | Chờ Tech Lead + Ops/SRE xác nhận `OQ-010`/`OQ-026`/`OQ-027` |
|
||
|
||
> Đây là ghi nhận **review nội dung**, không phải "sign" theo nghĩa gate: `Status` giữ nguyên
|
||
> `Proposed`. Xem `00-index/ADL_e-commerce.md` (Change Log — Review 2026-09-15) và `ADL §8`
|
||
> "Việc phải làm" cho điều kiện chuyển `Accepted`. Confidence tổng thể của lượt review: 🔴 —
|
||
> `AG2` chưa ký.
|