189 lines
16 KiB
Markdown
189 lines
16 KiB
Markdown
# IMPACT — Phân tích tác động — Giỏ hàng & Checkout (e-commerce)
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Version** | 1.0 |
|
|
| **Date** | 2026-09-08 |
|
|
| **Author** | BA (qua skill ba-2-analysis) |
|
|
| **Status** | 🟡 Draft |
|
|
| **Approved by** | — *(cần Tech Lead xác nhận — chưa có Tech Lead thật tham gia lần chạy này)* |
|
|
| **Profile** | screen · greenfield · standard |
|
|
| **Source** | `01-discovery/BRIEF_CartCheckout_v1.0.md` §5.3 (ranh giới hệ thống) · `01-discovery/RISK_CartCheckout_v1.0.md` §3 (phụ thuộc bên ngoài) · `PROCESS_CartCheckout_v1.0.md` · `e-commerce/docs/sections/06-luong-xu-ly.md` §6.1.1 (tham chiếu tích hợp, không chép thiết kế) |
|
|
| **Scope** | Module Giỏ hàng & Checkout — RQ-001…RQ-004 |
|
|
|
|
## Change Log
|
|
|
|
| Version | Date | Người sửa | Thay đổi | CR |
|
|
|---|---|---|---|---|
|
|
| 1.0 | 2026-09-08 | BA (qua skill ba-2-analysis) | Bản đầu — rút gọn theo `LIFECYCLE = greenfield`, trọng tâm trục tích hợp | — |
|
|
|
|
---
|
|
|
|
> ⚠️ **Ngoại lệ gate G1** — xem cảnh báo đầy đủ ở đầu `PROCESS_CartCheckout_v1.0.md` và `DEC-02`
|
|
> ở `00-index/DECISION_e-commerce.md`.
|
|
>
|
|
> **Vì sao tài liệu này rút gọn:** theo `00-index/PROFILE_e-commerce.md` mục "Hệ quả đã áp
|
|
> dụng" (`LIFECYCLE = greenfield`): *"GĐ2 `IMPACT` rút gọn: chỉ trục tích hợp (không có
|
|
> module/dữ liệu cũ bị ảnh hưởng)"*. Tài liệu dưới đây vẫn rà đủ **sáu trục** theo template
|
|
> (không bỏ giai đoạn im lặng) — năm trục còn lại ghi rõ *"đã rà, không phát hiện"* kèm lý do
|
|
> greenfield; trục 1.5 (Tích hợp) là trọng tâm thật sự của tài liệu này.
|
|
|
|
---
|
|
|
|
## 0. Kết luận
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Mức tác động tổng thể** | 🟠 Trung bình — không có gì để đụng ở màn hình/dữ liệu/BR/RBAC cũ (greenfield), nhưng **tích hợp với 4 bên thứ ba (VNPay, Momo, GHN, GHTK) + 3 module nội bộ song song (Catalog, Commission & Payout, Promotion & Loyalty, Notification) đều chưa được xác minh khả thi** |
|
|
| **Số hạng mục 🔴** | 2 (VNPay, Momo — xem §1.5) |
|
|
| **Cần migrate dữ liệu** | Không — `LIFECYCLE = greenfield`, không có dữ liệu cũ (xác nhận F7, `ELICITATION_CartCheckout_2026-09-08.md`) |
|
|
| **Cần phối hợp bên thứ ba** | Có — VNPay, Momo, GHN, GHTK (xem §1.5) |
|
|
| **Rủi ro lớn nhất** | `RISK-02` (webhook thanh toán trễ/lỗi khiến đơn kẹt "chờ thanh toán") và `RISK-01` (COD bùng đơn một phần) — cả hai đã ghi ở GĐ1, ảnh hưởng trực tiếp tới khả năng chốt `BR-CART-03`/`BR-CART-06` ở GĐ2 này |
|
|
|
|
---
|
|
|
|
## 1. Sáu trục rà soát
|
|
|
|
### 1.1 Màn hình / chức năng hiện có
|
|
|
|
| Màn hình/chức năng | Đường dẫn | Tác động | Mức | Phương án | Ai xác nhận |
|
|
|---|---|---|---|---|---|
|
|
| *(không có)* | — | — | — | — | — |
|
|
|
|
**Đã rà:** đã kiểm tra `ba-output/e-commerce/` (chỉ có artifact GĐ1 của chính module này) và
|
|
`e-commerce/docs/sections/07-giao-dien.md` (mô tả UI dạng văn bản SCR-01…, chưa phải màn hình
|
|
đã build). **Kết luận: không có màn hình nào đang chạy để module này tác động** — đây là module
|
|
đầu tiên chạy GĐ2 của dự án e-commerce (greenfield, chưa có bản build sản phẩm nào trước đó).
|
|
|
|
### 1.2 Dữ liệu
|
|
|
|
| Bảng/thực thể | Thay đổi | Số bản ghi hiện có | Dữ liệu cũ xử lý thế nào | Mức | Ai xác nhận |
|
|
|---|---|---|---|---|---|
|
|
| *(không có)* | — | 0 | N/A | — | — |
|
|
|
|
**Đã rà:** đối chiếu `e-commerce/docs/sections/05-thiet-ke-du-lieu.md` §5.3.5 *"Migration dữ
|
|
liệu cũ: Không áp dụng — dự án greenfield… không có hệ thống cũ cần tích hợp/migrate"*. **Kết
|
|
luận: không có dữ liệu cũ.** Toàn bộ thực thể mới (`Cart`, `CartItem`, `Order`, `OrderSeller`,
|
|
`OrderItem`, `Payment` — xem `BR_CartCheckout_v1.0.md` §4) được tạo mới hoàn toàn; không thuộc
|
|
ba lựa chọn "giữ nguyên/migrate/song song" vì không có dữ liệu cũ để chọn.
|
|
|
|
### 1.3 Business rule
|
|
|
|
| BR hiện hành | Bị ảnh hưởng thế nào | Mâu thuẫn với rule mới? | Xử lý | Mức |
|
|
|---|---|---|---|---|
|
|
| *(không có)* | — | — | — | — |
|
|
|
|
**Đã rà:** không có `BR` nào đã chốt (`✅ Baselined`) trước module này trong toàn dự án
|
|
e-commerce — đây là bộ `BR` đầu tiên (`BR_CartCheckout_v1.0.md`). Mâu thuẫn **nội bộ** giữa các
|
|
rule mới của chính module này đã được rà ở `BR_CartCheckout_v1.0.md` §6, không lặp lại ở đây.
|
|
|
|
### 1.4 Phân quyền
|
|
|
|
| Vai trò | Thay đổi quyền | Ai bị mất quyền | Đã thông báo | Mức |
|
|
|---|---|---|---|---|
|
|
| *(không có)* | — | — | — | — |
|
|
|
|
**Đã rà:** không có `RBAC` nào đã chốt trước module này. `RBAC_CartCheckout_v1.0.md` tạo mới
|
|
2 vai trò (Guest, Customer) — chưa ảnh hưởng vai trò nào đã tồn tại vì đây là module đầu tiên.
|
|
|
|
### 1.5 Tích hợp / hệ thống ngoài — TRỌNG TÂM
|
|
|
|
| Hệ thống | Điểm chạm | Thay đổi | Đầu mối bên kia | Cần bên kia làm gì | Hạn | Mức |
|
|
|---|---|---|---|---|---|---|
|
|
| VNPay | Payment Service khởi tạo giao dịch (US-008) + nhận webhook xác nhận (BR-CART-06) | Tích hợp mới hoàn toàn | Chưa xác định (`RISK` §3 phụ thuộc #1) | Cung cấp tài liệu API + tài khoản sandbox; xác nhận cơ chế/độ trễ webhook (`ASM-01`/`OQ-010`) | Trước khi bắt đầu GĐ3 (SRS thanh toán) | 🔴 |
|
|
| Momo | Tương tự VNPay | Tích hợp mới hoàn toàn | Chưa xác định (`RISK` §3 phụ thuộc #2) | Tương tự VNPay | Trước GĐ3 | 🔴 |
|
|
| GHN | Ước tính phí ship/kiểm tra vùng phục vụ theo địa chỉ lúc checkout (US-005) | Tích hợp mới | Chưa xác định (`RISK` §3 phụ thuộc #3) | Cung cấp API tính phí + vùng phục vụ (`ASM-02`/`OQ` GĐ1) | Trước GĐ3 (SRS checkout) | 🟠 |
|
|
| GHTK | Tương tự GHN | Tích hợp mới | Chưa xác định (`RISK` §3 phụ thuộc #4) | Tương tự GHN | Trước GĐ3 | 🟠 |
|
|
| Catalog & Inventory (module nội bộ, cùng dự án, ngoài phạm vi RQ-001…004) | Cart đọc giá/tồn kho khi thêm giỏ (US-001) và giữ tồn kho khi checkout (US-004, BR-CART-02) | Tích hợp nội bộ mới (một chiều vào Cart) | STK-06 (Tech Lead) | Xác nhận kiến trúc đồng bộ giá/tồn kho, độ trễ cache (`ASM-06`/`OQ-009`) | Trước GĐ3 | 🟠 |
|
|
| Commission & Payout (module nội bộ, ngoài phạm vi) | Nhận sự kiện thanh toán thành công để tạo bản ghi hoa hồng | Tích hợp nội bộ mới (một chiều ra khỏi module này) | STK-06 (Tech Lead) | Xác nhận cấu trúc sự kiện cần thiết | Trước GĐ3 | 🟢 |
|
|
| Notification (module nội bộ, ngoài phạm vi, FR-12) | Nhận sự kiện "đơn đã tạo"/"thanh toán thành công" để trigger gửi email/SMS | Tích hợp nội bộ mới (một chiều ra khỏi module này) | STK-06 (Tech Lead) | Xác nhận điều kiện trigger | Trước GĐ3 | 🟢 |
|
|
| Khuyến mãi & Loyalty (module nội bộ, ngoài phạm vi, FR-13/14) | Checkout gọi API "áp dụng mã/điểm" và hiển thị kết quả giảm giá đã tính (điểm tích hợp đã xác nhận qua `OQ-004`, xem `DEC-03`) | Tích hợp nội bộ mới (hai chiều: gọi áp dụng + nhận kết quả) | STK-01 (PO sàn) đã xác nhận điểm nối; **đầu mối kỹ thuật (API contract) chưa xác định** | Cung cấp API "áp dụng mã/điểm" trả về giá trị giảm | Trước GĐ3 (màn hình checkout, US-004/US-005) | 🟠 |
|
|
|
|
**Nếu bên kia lỗi hoặc chậm thì nghiệp vụ này xử lý thế nào? *(bắt buộc trả lời)***
|
|
|
|
- **VNPay/Momo lỗi/chậm (timeout, không gửi webhook):** theo `PROCESS_CartCheckout_v1.0.md`
|
|
bước B9 — đơn giữ `pending_payment`; cơ chế đối soát bù (reconciliation job) được đề xuất ở
|
|
`RISK-02` (GĐ1) nhưng **thiết kế chi tiết thuộc phạm vi module Thanh toán ở GĐ3, không phải
|
|
một US của module Giỏ hàng & Checkout**. Đây là phụ thuộc bắt buộc phải xử lý trước go-live,
|
|
ghi nhận rõ để không rơi vào khoảng trống giữa hai module.
|
|
- **GHN/GHTK lỗi/chậm lúc ước tính phí ship (US-005):** nếu `ASM-02` sai (API không khả dụng
|
|
thời gian thực lúc checkout), phương án dự phòng là chuyển sang ước tính tĩnh — **chưa được
|
|
PO/Tech Lead xác nhận là phương án chính thức**, vẫn ở dạng giả định từ GĐ1.
|
|
- **Catalog & Inventory chậm/không phản hồi:** có thể chặn hoàn toàn bước thêm giỏ (US-001)
|
|
hoặc checkout (US-004) vì đây là phụ thuộc cứng (không có giá/tồn kho thì không tạo được
|
|
`CartItem`/`OrderItem` hợp lệ) — cần Tech Lead xác nhận SLA nội bộ giữa hai service, ngoài
|
|
khả năng BA tự quyết.
|
|
- **Khuyến mãi & Loyalty lỗi/chậm:** theo `OQ-004`/`DEC-03`, module này chỉ hiển thị kết quả đã
|
|
tính — nếu API áp dụng lỗi, hành vi hiển thị cho khách (bỏ qua coupon/điểm, hay chặn checkout
|
|
hoàn toàn) **chưa chốt, cần OQ mới ở GĐ3**.
|
|
|
|
**Đã rà:** đối chiếu `BRIEF_CartCheckout_v1.0.md` §5.3 (ranh giới hệ thống) và
|
|
`RISK_CartCheckout_v1.0.md` §3 (phụ thuộc bên ngoài) — không phát hiện hệ thống tích hợp nào
|
|
khác ngoài bảng trên trong phạm vi RQ-001…004.
|
|
|
|
### 1.6 Báo cáo / đối soát
|
|
|
|
*Rút gọn theo `LIFECYCLE = greenfield` (theo quyết định ở `PROFILE`) — không có báo cáo hiện
|
|
hành nào bị đổi cách tính vì đây là module đầu tiên, chưa từng có báo cáo trước đó.*
|
|
|
|
| Báo cáo | Số liệu nào đổi | Đổi từ khi nào | Ai dùng báo cáo này | Đã báo chưa | Mức |
|
|
|---|---|---|---|---|---|
|
|
| *(không có báo cáo hiện hành để đổi)* | — | — | — | — | — |
|
|
|
|
**Ghi nhận (không phải "tác động" theo nghĩa template, nhưng quan trọng để không bỏ sót):**
|
|
dữ liệu `Order`/`OrderSeller`/`Payment` do module này sinh ra là **đầu vào bắt buộc** cho báo
|
|
cáo đối soát doanh thu tương lai (STK-04 Kế toán đối soát, `RACI` ở `STAKEHOLDER` GĐ1) — nhưng
|
|
vì chưa có báo cáo nào tồn tại để so sánh, mục này không có gì để điền theo đúng cấu trúc bảng
|
|
trên. Đây là lý do `RISK-02` (webhook trễ) quan trọng: dữ liệu sai lệch ngay từ module này sẽ
|
|
lan sang mọi báo cáo đối soát sau này — ghi chú lại để module Kế toán/Đối soát (nếu chạy GĐ1/2
|
|
riêng sau này) biết điểm phụ thuộc ngược.
|
|
|
|
---
|
|
|
|
## 2. Tác động lên người dùng và vận hành
|
|
|
|
| Vai trò | Thay đổi trong công việc | Cần đào tạo | Cần thông báo trước | Mức kháng cự dự kiến |
|
|
|---|---|---|---|---|
|
|
| Customer/Guest | Trải nghiệm hoàn toàn mới (không có công việc "cũ" bị thay đổi — greenfield) | Hướng dẫn UX tại chỗ (onboarding/tooltip) — thuộc `WF`/`UICONV` GĐ3 | Không áp dụng (chưa có người dùng cũ) | Thấp — nhưng chưa đo được thật (chưa vận hành), xem `GOAL-01` |
|
|
| CSKH *(ngoài phạm vi stakeholder module này, nhưng liên đới qua `RISK-02`)* | Có thể cần quy trình mới để xử lý đơn "kẹt chờ thanh toán" — **chưa có quy trình chính thức nào được thiết kế trong phạm vi module này** | Chưa xác định — phụ thuộc thiết kế cơ chế đối soát bù ở GĐ3 module Thanh toán | Cần thông báo trước go-live nếu quy trình này được xác nhận | Chưa đánh giá được — chưa có CSKH thật tham gia (đúng hệ quả G1 chưa ký) |
|
|
|
|
## 3. Tác động lên phi chức năng
|
|
|
|
| Khía cạnh | Tác động | Ngưỡng hiện tại | Ngưỡng sau thay đổi | Cần đo lại |
|
|
|---|---|---|---|---|
|
|
| Hiệu năng | Checkout (B1→B5, `PROCESS`) phải hoàn tất trong ngưỡng đề xuất | N/A — chưa vận hành | < 3 giây (đề xuất `NFR-01`, chưa phải SLA hợp đồng — xem `BRIEF` §2) | ☑ (bắt buộc đo ở soft-launch, theo `GOAL-01`/`GOAL-02`) |
|
|
| Dung lượng lưu trữ | Chưa đo — greenfield, không có dữ liệu lịch sử để ước lượng tăng trưởng thật | N/A | N/A | ☑ (sau khi có số liệu vận hành thật, không phải việc của GĐ2) |
|
|
| Bảo mật / tuân thủ | Chia sẻ PII (địa chỉ, SĐT) cho seller khi tách đơn (`RISK-03`) chưa được Pháp chế/Bảo mật rà soát | N/A | N/A — chờ người phụ trách (`OQ-003`, GĐ1) | ☑ (bắt buộc trước go-live, không phải "nên làm") |
|
|
|
|
## 4. Thứ tự triển khai bắt buộc
|
|
|
|
| # | Việc | Phải xong trước | Vì sao | Ai làm |
|
|
|---|---|---|---|---|
|
|
| 1 | Xác minh `ASM-01` (webhook VNPay/Momo khả thi gần thời gian thực) | Thiết kế chi tiết `SRS` US-008 ở GĐ3 | Nếu sai, toàn bộ luồng xác nhận thanh toán (BR-CART-06) phải đổi cơ chế sang polling | Tech Lead |
|
|
| 2 | Xác minh `ASM-02` (API GHN/GHTK tính phí ship real-time) | Thiết kế chi tiết `SRS` US-005 ở GĐ3 | Nếu sai, phải đổi sang phương án ước tính tĩnh — thay đổi UX hiển thị phí ship | Tech Lead + STK-05 (Trưởng vận hành) |
|
|
| 3 | PO trả lời `OQ-006` (giới hạn COD) | Chốt `BR-CART-03` trước khi viết `AC` của US-007 ở GĐ3 | Không có con số thì không viết được điều kiện chặn/cảnh báo cụ thể | PO, Kế toán đối soát |
|
|
| 4 | Xác nhận API contract "áp dụng mã/điểm" với module Khuyến mãi & Loyalty | Thiết kế màn hình checkout (US-004/US-005) ở GĐ3 | Module này chỉ hiển thị kết quả đã tính — không tự thiết kế được UI nếu chưa biết dữ liệu trả về là gì | Tech Lead, PO |
|
|
|
|
## 5. Phạm vi hồi quy đề xuất cho QA
|
|
|
|
| Khu vực cần test lại | Vì sao | Ưu tiên |
|
|
|---|---|---|
|
|
| *(không có)* | Module đầu tiên chạy GĐ2 của dự án e-commerce — chưa có tính năng nào đã release để hồi quy (greenfield, `RIGOR = standard` không miễn hoàn toàn nghĩa vụ ghi mục này, nhưng nội dung thật sự là "không có" vì chưa có bản release nào trước đó) | N/A |
|
|
|
|
## 6. Open Questions
|
|
|
|
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
|
|
|---|---|---|---|---|
|
|
| OQ-009 | `ASM-06` — giá/tồn kho thay đổi giữa lúc thêm giỏ và checkout | PO + Tech Lead | 2026-09-08 | §1.5 dòng Catalog & Inventory |
|
|
| OQ-010 | Xác nhận khả thi `ASM-01` (webhook VNPay/Momo) | Tech Lead | 2026-09-08 | §1.5 dòng VNPay/Momo, §4 mục 1 |
|
|
| *(GĐ1)* ASM-02 | Xác nhận API GHN/GHTK tính phí ship real-time | Tech Lead, STK-05 | 2026-09-08 | §1.5 dòng GHN/GHTK, §4 mục 2 |
|
|
| *(mới)* OQ-017 | Nếu API "áp dụng mã/điểm" của module Khuyến mãi & Loyalty lỗi/chậm lúc checkout, hệ thống bỏ qua và cho tiếp tục hay chặn checkout hoàn toàn? | PO, Tech Lead | 2026-09-08 | §1.5 dòng Khuyến mãi & Loyalty |
|
|
|
|
## 7. Xác nhận
|
|
|
|
| Vai trò | Người | Xác nhận nội dung | Ngày |
|
|
|---|---|---|---|
|
|
| Tech Lead | *(chưa có — chưa xác định tên thật, xem `OQ-001` GĐ1)* | ☐ Khả thi, đã rà đủ | — |
|
|
| QA | *(chưa có)* | ☐ Phạm vi hồi quy hợp lý (N/A cho module đầu tiên) | — |
|
|
| PO | *(chưa có — chưa xác định tên thật, xem `OQ-001` GĐ1)* | ☐ Chấp nhận tác động lên người dùng | — |
|