sys-analysis-design/e-commerce/docs/00-project-brief.md

version, status, round

version	status	round
3	ready	3

Project Brief

1. Mô tả gốc từ người dùng

"e-commece" — hệ thống thương mại điện tử. Không có mô tả chi tiết nào khác được cung cấp ban đầu (không rõ mô hình kinh doanh, tính năng, quy mô, ràng buộc kỹ thuật). Qua vòng 1, người dùng đã xác nhận đây là sàn marketplace đa người bán (multi-seller), không phải bán lẻ single-vendor. Qua vòng 2-3, người dùng đã làm rõ cơ chế vận hành marketplace (hoa hồng theo ngành hàng, KYC thủ công, payout hàng tuần), phạm vi tuân thủ pháp lý, chi tiết loyalty, danh sách ngôn ngữ mở rộng (5 ngôn ngữ), và xác nhận không có ràng buộc tech stack/cloud/hệ thống cũ.

2. Mô hình tham chiếu đề xuất (đánh dấu: đã xác nhận / đã loại / chờ xác nhận)

Mô hình: Marketplace thương mại điện tử đa người bán (multi-vendor B2C/B2B2C), quy mô lớn. — đã xác nhận (vòng 1)

Actor chuẩn

• Khách vãng lai (Guest) — duyệt sản phẩm, thêm giỏ hàng, checkout không cần tài khoản — đã xác nhận
• Khách hàng đã đăng ký (Customer) — quản lý tài khoản, lịch sử đơn hàng, wishlist, điểm thưởng/hạng thành viên — đã xác nhận
• Người bán thứ ba (Seller/Vendor) — đăng ký, KYC, đăng bán, quản lý tồn kho/đơn hàng riêng, nhận payout, dashboard người bán — đã xác nhận (do marketplace)
• Quản trị viên sàn (Platform Admin) — quản lý seller (duyệt KYC/khoá), catalog toàn sàn, cấu hình bảng hoa hồng theo ngành hàng, khuyến mãi, tranh chấp — đã xác nhận
• Nhân viên vận hành/kho (Ops/Warehouse staff, có thể thuộc sàn hoặc seller) — xử lý tồn kho, đóng gói, giao hàng — đã xác nhận
• Nhân viên CSKH (CSR) — xử lý khiếu nại, đổi trả, tranh chấp giữa khách và seller — đã xác nhận

Bộ tính năng MVP chuẩn

• Danh mục & tìm kiếm sản phẩm (catalog, filter, search, đa seller) — đã xác nhận
• Giỏ hàng & checkout (hỗ trợ giỏ hàng đa seller trong 1 đơn) — đã xác nhận
• Thanh toán (VNPay/Momo + COD) — đã xác nhận
• Quản lý đơn hàng (tạo, theo dõi trạng thái, huỷ, đổi trả, tách đơn theo seller) — đã xác nhận
• Tài khoản khách hàng (đăng ký/đăng nhập, địa chỉ, lịch sử đơn hàng) — đã xác nhận
• Quản trị sản phẩm & tồn kho (cho seller tự quản lý + admin giám sát) — đã xác nhận
• Khuyến mãi/mã giảm giá cơ bản — đã xác nhận
• Đánh giá & review sản phẩm — đã xác nhận
• Thông báo (email/SMS xác nhận đơn hàng) — đã xác nhận
• Seller onboarding & KYC: seller tự đăng ký, upload giấy phép kinh doanh/CMND, admin duyệt thủ công — đã xác nhận (vòng 3)
• Hoa hồng (commission): tính theo bảng cấu hình theo ngành hàng (category), admin chỉnh được; chưa phân biệt theo seller tier ở MVP — đã xác nhận (vòng 3)
• Payout cho seller: định kỳ hàng tuần, qua chuyển khoản ngân hàng, có kỳ giữ tiền (hold) sau giao hàng thành công 3-7 ngày để xử lý đổi trả — đã xác nhận cơ chế (vòng 3); số ngày hold cụ thể = giả định mặc định, xem mục 5
• Loyalty/điểm thưởng: tích 1 điểm/10.000đ, 100 điểm = 10.000đ giảm giá, 3 hạng Bạc/Vàng/Kim cương theo tổng chi tiêu 12 tháng — giả định mặc định đã chốt (vòng 3), xem mục 5
• Đa ngôn ngữ: Tiếng Việt (mặc định), Tiếng Anh, Tiếng Trung, Tiếng Hàn, Tiếng Nhật (VI/EN/ZH/KO/JA) — đã xác nhận, mở rộng so với đề xuất ban đầu (vòng 3)
• Đa tiền tệ: giao dịch bằng VND; hiển thị quy đổi tham khảo sang các tiền tệ khác; không giao dịch trực tiếp bằng ngoại tệ ở MVP — đã xác nhận (vòng 3)
• Hoá đơn điện tử cho seller — hoãn sang giai đoạn sau, đã xác nhận (vòng 3)

Ngoài phạm vi MVP (giai đoạn sau, đã xác nhận): Affiliate marketing, subscription/bán hàng định kỳ, ứng dụng mobile native (phase 1 chỉ web responsive), hoá đơn điện tử tự động cho seller, phân biệt commission theo seller tier.

NFR tiêu biểu

• Quy mô: lớn — hàng trăm nghìn SKU trở lên, hàng trăm nghìn đến hàng triệu user đăng ký, peak hàng nghìn đến hàng chục nghìn concurrent users mùa flash sale — đã xác nhận (vòng 1)
• Kiến trúc cần: cache (Redis), CDN, message queue (Kafka/RabbitMQ), khả năng scale-out ngang ngay từ đầu, triển khai trên AWS — đã xác nhận
• Độ trễ mục tiêu: trang sản phẩm/tìm kiếm < 2s, checkout < 3s ngay cả khi tải đỉnh — giả định mặc định đã chốt (không có phản hồi trái ngược qua các vòng)
• Uptime mục tiêu: 99.9% (do quy mô lớn, marketplace, doanh thu phụ thuộc hệ thống) — giả định mặc định đã chốt
• Có PII (khách hàng + seller, giấy tờ KYC) và có thanh toán (payment + payout cho seller) → phạm vi tuân thủ: NĐ52/85 (thông báo website TMĐT marketplace với Bộ Công Thương), NĐ13/2023 (bảo vệ dữ liệu cá nhân), PCI-DSS scope giảm (không lưu thẻ, giao VNPay/Momo xử lý) — giả định mặc định đã chốt (vòng 3)
• Xác thực & bảo mật: không cần SSO/IdP doanh nghiệp (không có khách hàng B2B enterprise ở MVP); Customer có thể đăng nhập email/password + tuỳ chọn Google/Facebook social login; Admin bắt buộc MFA, Seller khuyến khích MFA — giả định mặc định đã chốt (vòng 3, nice-to-have)

Tích hợp thường gặp

• Cổng thanh toán: VNPay, Momo + COD — đã xác nhận (dùng mặc định vòng 1)
• Vận chuyển: GHN, GHTK — đã xác nhận (dùng mặc định vòng 1)
• Email/SMS: gửi thông báo đơn hàng (SendGrid/Twilio hoặc dịch vụ nội địa) — đề xuất, chưa chọn cụ thể (nice-to-have, để kiến trúc sư quyết định)
• Payout cho seller: chuyển khoản ngân hàng hàng tuần, không cần thêm ví điện tử trung gian ở MVP — đã xác nhận (vòng 3)
• Google/Facebook social login cho Customer (nice-to-have) — giả định mặc định đã chốt (vòng 3)
• Không có ERP/kho/CRM cũ cần tích hợp hoặc migrate — dự án mới hoàn toàn — đã xác nhận (vòng 3)

3. Hồ sơ dự án (profile)

• scale: large (hàng trăm nghìn SKU+, hàng trăm nghìn–hàng triệu user, peak hàng nghìn–chục nghìn concurrent)
• hasPayment: true (thanh toán khách hàng qua VNPay/Momo/COD + payout hàng tuần cho seller qua chuyển khoản ngân hàng)
• hasPII: true (dữ liệu khách hàng, dữ liệu seller bao gồm giấy tờ KYC — giấy phép kinh doanh/CMND)
• platforms: ["web"] — mobile app native là phase 2 (giả định đã chốt, dùng mặc định vòng 1)
• integrations: ["VNPay", "Momo", "COD", "GHN", "GHTK", "email/SMS notification (nhà cung cấp cụ thể chưa chọn)", "bank transfer cho seller payout", "Google/Facebook OAuth (nice-to-have)"]
• cloud/hạ tầng: AWS, dự án mới hoàn toàn (greenfield), không có hệ thống cũ cần tích hợp/migrate
• notApplicableSections: Affiliate, subscription/bán hàng định kỳ, mobile app native, commission theo seller tier, hoá đơn điện tử tự động cho seller, SSO doanh nghiệp (IdP) — tất cả hoãn sang giai đoạn sau, không phải "không áp dụng" vĩnh viễn.

4. Q&A log

Vòng	Câu hỏi	Trả lời
1	Hệ thống là cửa hàng bán lẻ một người bán (single-vendor B2C) hay sàn thương mại điện tử đa người bán (marketplace)?	Marketplace đa người bán — có seller thứ ba đăng ký bán, sàn thu hoa hồng, payout cho seller, dashboard người bán.
1	Xác nhận/loại bỏ/bổ sung bộ tính năng MVP (catalog & tìm kiếm, giỏ hàng, checkout, thanh toán, quản lý đơn hàng, tài khoản khách hàng, quản trị sản phẩm/tồn kho, khuyến mãi cơ bản, đánh giá sản phẩm, thông báo email/SMS)?	Giữ toàn bộ MVP đề xuất VÀ bổ sung ngay từ MVP: (1) loyalty/điểm thưởng; (2) đa ngôn ngữ và đa tiền tệ. Affiliate và subscription vẫn để phase 2.
1	Quy mô dự kiến: số lượng SKU, số user đăng ký, tải đỉnh (concurrent users, mùa flash sale)?	Lớn — hàng trăm nghìn SKU trở lên, hàng trăm nghìn đến hàng triệu user đăng ký, peak hàng nghìn đến hàng chục nghìn concurrent users mùa sale. Cần cache/CDN/message queue/scale-out ngay từ đầu.
1	Nền tảng client: chỉ web responsive hay cần mobile app ngay từ MVP? Đối tác thanh toán/vận chuyển cụ thể?	Dùng mặc định — Web responsive cho MVP, mobile app ở phase 2; thanh toán VNPay/Momo + COD; vận chuyển GHN/GHTK.
3	Cơ chế vận hành marketplace: quy trình seller onboarding/KYC, cách tính hoa hồng (commission), chu kỳ và kênh payout cho seller?	Hoa hồng tính theo ngành hàng (bảng commission cấu hình theo category, chỉnh được bởi admin, chưa theo seller tier). KYC thủ công: seller tự đăng ký, upload giấy phép kinh doanh/CMND, admin duyệt. Payout hàng tuần qua chuyển khoản ngân hàng, có kỳ giữ tiền (hold) sau giao hàng thành công (dùng mặc định 3-7 ngày).
3	Nghĩa vụ tuân thủ pháp lý cho sàn TMĐT Việt Nam?	Dùng mặc định — áp dụng đầy đủ: thông báo website TMĐT marketplace với Bộ Công Thương theo NĐ52/85; tuân thủ NĐ13/2023 bảo vệ dữ liệu cá nhân; PCI-DSS giảm scope (không lưu thẻ, giao VNPay/Momo xử lý); hoá đơn điện tử cho seller để giai đoạn sau.
3	Chi tiết chương trình loyalty và danh sách ngôn ngữ/tiền tệ MVP?	Loyalty dùng mặc định (tích 1 điểm/10.000đ, 100 điểm = 10.000đ giảm giá, 3 hạng Bạc/Vàng/Kim cương theo tổng chi tiêu 12 tháng). Ngôn ngữ mở rộng: VI (mặc định)/EN/ZH/KO/JA. Tiền tệ: giao dịch VND, hiển thị quy đổi tham khảo các tiền tệ khác, không giao dịch trực tiếp ngoại tệ ở MVP.
3	Ràng buộc dự án: ngân sách, timeline, tech stack bắt buộc, cloud provider, hệ thống cũ cần tích hợp/migrate?	Dùng mặc định — không có tech stack/cloud bắt buộc, kiến trúc sư tự đề xuất theo best practice cho quy mô lớn; cloud AWS; dự án mới hoàn toàn, không có ERP/kho/CRM cũ; ngân sách/timeline chưa xác định.

5. Giả định đã chốt (từ mặc định, kèm rủi ro)

• Nền tảng client MVP = web responsive, mobile app = phase 2. Rủi ro: nếu phần lớn traffic mục tiêu thực tế đến từ mobile app native, trải nghiệm và tỷ lệ chuyển đổi MVP có thể thấp hơn kỳ vọng; cần bổ sung roadmap mobile sớm hơn nếu dữ liệu thị trường cho thấy nhu cầu cao.
• Cổng thanh toán = VNPay + Momo + COD; vận chuyển = GHN + GHTK. Rủi ro: nếu doanh nghiệp đã có hợp đồng/ưu đãi với đối tác khác, cần thay đổi tích hợp và có thể phát sinh chi phí/thời gian điều chỉnh thiết kế.
• Kỳ giữ tiền (payout hold) = 3-7 ngày sau giao hàng thành công. Rủi ro: nếu chính sách đổi trả thực tế của doanh nghiệp dài hơn (vd. 15-30 ngày cho một số ngành hàng), dòng tiền payout và mô hình đối soát (reconciliation) cần điều chỉnh lại; có thể phát sinh tranh chấp với seller nếu thời gian hold không rõ ràng trong hợp đồng seller.
• Tuân thủ pháp lý = áp dụng đầy đủ NĐ52/85 (thông báo website TMĐT), NĐ13/2023 (bảo vệ dữ liệu cá nhân), PCI-DSS scope giảm qua cổng thanh toán bên thứ ba; hoá đơn điện tử cho seller hoãn phase 2. Rủi ro: nếu doanh nghiệp thực tế cần cấp phép "Sàn giao dịch TMĐT" đầy đủ (không chỉ thông báo) do quy mô/mô hình kinh doanh cụ thể, cần rà soát pháp lý bổ sung trước khi go-live; thiếu hoá đơn điện tử cho seller ở MVP có thể gây khó khăn vận hành kế toán cho seller.
• Chương trình loyalty: 1 điểm/10.000đ, 100 điểm = 10.000đ giảm giá, 3 hạng Bạc/Vàng/Kim cương theo chi tiêu 12 tháng gần nhất. Rủi ro: nếu chiến lược kinh doanh thực tế muốn cơ chế tích/đổi điểm khác (vd. theo ngành hàng, theo chương trình đối tác), cần điều chỉnh mô hình dữ liệu loyalty và luồng tính điểm.
• Độ trễ mục tiêu <2s (catalog/search), <3s (checkout); uptime mục tiêu 99.9%. Rủi ro: nếu SLA hợp đồng với đối tác/khách hàng doanh nghiệp yêu cầu cao hơn (vd. 99.95%+), cần đầu tư thêm cho multi-AZ/multi-region và có thể tăng chi phí hạ tầng đáng kể.
• Tech stack không bắt buộc, kiến trúc sư tự đề xuất theo best practice cho quy mô lớn; cloud = AWS; dự án greenfield, không có hệ thống cũ cần tích hợp/migrate; ngân sách/timeline chưa xác định (giả định theo lộ trình MVP tiêu chuẩn ~9-12 tháng, ngân sách theo business case). Rủi ro: nếu ngân sách/timeline thực tế bị giới hạn chặt hơn giả định, phạm vi MVP (đặc biệt các hạng mục mở rộng như 5 ngôn ngữ, loyalty, kiến trúc scale-out ngay từ đầu) có thể cần cắt giảm hoặc chia nhỏ thành nhiều release.
• Xác thực/bảo mật: không có SSO doanh nghiệp; Customer dùng email/password + tuỳ chọn Google/Facebook OAuth; Admin bắt buộc MFA, Seller khuyến khích MFA. Rủi ro: nếu về sau có đối tác B2B lớn yêu cầu tích hợp SSO/IdP riêng, cần bổ sung thiết kế xác thực liên kết (federation) sau này.
• UI/Brand: không có brand guideline cố định, dùng design system chuẩn (vd. Material/Ant Design) làm nền tảng; đa ngôn ngữ quản lý qua i18n framework cho 5 ngôn ngữ (VI/EN/ZH/KO/JA). Rủi ro: nếu doanh nghiệp có bộ nhận diện thương hiệu riêng cần tuân thủ nghiêm ngặt, giai đoạn thiết kế UI cần thời gian điều chỉnh thêm; bản dịch 5 ngôn ngữ cần quy trình quản lý nội dung đa ngôn ngữ (translation workflow) chưa được đặc tả chi tiết.
• Vận hành: môi trường Dev/Staging/Production trên AWS; đội vận hành (ops) trực theo ca; hỗ trợ giờ hành chính + escalation 24/7 cho sự cố nghiêm trọng (do doanh thu phụ thuộc hệ thống). Rủi ro: nếu tổ chức chưa có đội ops 24/7 sẵn sàng, cần lên kế hoạch tuyển dụng/thuê ngoài dịch vụ vận hành trước go-live.

6. Khoảng trống còn lại

Không còn khoảng trống Critical hoặc Important nào chưa được xử lý. Toàn bộ các mục còn lại (SSO/MFA, brand guideline, SLA vận hành, ngân sách/timeline, nhà cung cấp email/SMS cụ thể) đã được gán giả định mặc định ở mục 5 tại vòng cuối (vòng 3). Brief được coi là đủ đầy đủ để 9 agent SAD tiếp theo triển khai; các giả định nên được xác nhận lại với chủ dự án khi có điều kiện, đặc biệt: (a) thời gian hold payout, (b) phạm vi cấp phép pháp lý sàn TMĐT, (c) ngân sách/timeline thực tế.