PRD: Khuyến mãi, phương thức & quy tắc phân khúc
| Module | Định giá (CORE-14) | PRD ID | PRD-PROMO-001 |
| Trạng thái | Shipped | Phụ trách | Pricing squad |
| Ngày | 2026-06-15 | Phiên bản | v1.0 |
| Packages | @nx/pricing · @nx/core | URD | PROMO |
TL;DR
Cho phép merchant cấu hình một chiến dịch giảm giá như một đối tượng độc lập, hoàn chỉnh: một khuyến mãi mang đúng một phương thức (số tiền cố định hoặc phần trăm; nhắm vào dòng hàng, cả đơn hàng, hoặc vận chuyển; phân bổ theo từng món, trải đều, hoặc một lần) và một cơ chế là giảm giá thẳng (
STANDARD) hoặc deal mua-X-tặng-Y (BUY_GET). Ba tập quy tắc phân khúc chiến dịch - quy tắc điều kiện quyết định ai/khi nào đủ điều kiện, quy tắc nguồn quyết định cần mua gì, quy tắc đích quyết định cái gì được giảm. Toàn bộ đồ thị - khuyến mãi, phương thức và cả ba tập quy tắc - được tạo và sửa trong một aggregate nguyên tử với số đếm quy tắc denormalized luôn chính xác. Việc áp giảm giá khi thanh toán là một bước tăng trưởng sau này có chủ đích; PRD này bàn giao bề mặt cấu hình.
1. Bối cảnh & Vấn đề
Định giá đã chọn fare (FARE) và tính thuế (TAX), nhưng merchant chưa có cách diễn đạt một chiến dịch giảm giá - "giảm 10% đồ uống trước 17h", "mua 2 cà phê tặng 1", "giảm 50.000₫ cho đơn trên 300.000₫". Một chiến dịch không phải là một fare: nó trải trên nhiều dòng hàng, có thể nhắm vào đơn hàng hoặc vận chuyển thay vì một món, và phải nói không chỉ giảm bao nhiêu mà còn ai đủ điều kiện, cái gì kích hoạt, và cái gì được giảm.
Không có đối tượng khuyến mãi hạng nhất, chủ cửa hàng hoàn toàn không thể dựng các ưu đãi này, và dữ liệu cần để áp chúng khi thanh toán cũng không tồn tại. Bước tăng trưởng này lấp khoảng trống cấu hình: cho chủ cửa hàng một khuyến mãi với một phương thức, một cơ chế tiêu chuẩn hoặc mua-tặng, và ba tập quy tắc riêng biệt, tất cả được soạn và sửa như một đơn vị nguyên tử - nên một chiến dịch luôn được lưu trọn vẹn hoặc không lưu gì cả, không bao giờ dựng dở.
2. Mục tiêu & Phi mục tiêu
Mục tiêu
- Một đối tượng khuyến mãi với cơ chế (
STANDARDhoặcBUY_GET), một mã hoặc kích hoạt tự động, khoảng thời gian hiệu lực, giới hạn lượt dùng và trạng thái vòng đời. - Đúng một phương thức cho mỗi khuyến mãi khai báo cơ chế:
FIXED/PERCENTAGE, một đích (ITEMS/ORDER/SHIPPING), một phân bổ (EACH/ACROSS/ONCE), và giới hạn số lượng được giảm. - Hỗ trợ mua-tặng: một phương thức khai báo số lượng nguồn tối thiểu (phải mua) và số lượng đích (được giảm).
- Ba tập quy tắc phân khúc - điều kiện (trên khuyến mãi), nguồn và đích (trên phương thức) - dùng lại mô hình quy tắc chung (thuộc tính, toán tử, giá trị, logic AND).
- Một aggregate nguyên tử cho tạo và cập nhật trên khuyến mãi + phương thức + mọi tập quy tắc, với số đếm quy tắc denormalized luôn chính xác và trộn quy tắc theo hình dạng khi cập nhật.
- Xóa lan truyền loại bỏ phương thức và mọi quy tắc đính kèm cùng khuyến mãi.
Phi mục tiêu
- Áp giảm giá khuyến mãi khi định giá lúc thanh toán - bộ tính chưa được đấu nối vào bất kỳ luồng mô phỏng nào (URD-PROMO-006, vẫn là Won't trong bước này).
- Chọn fare và tính thuế - thuộc FARE và TAX.
- Quy đổi đa tiền tệ cho số tiền giảm (tiền tệ và tỷ giá được mang theo, không quy đổi ở đây).
- Lưu trữ đơn hàng, phát hành hóa đơn, tác động lên tồn kho hoặc thanh toán.
3. Chỉ số Thành công
| Chỉ số | Mục tiêu / dấu hiệu |
|---|---|
| Tính nguyên tử | Một bước con thất bại (thiếu trường quy tắc, không có phương thức) không lưu lại gì |
| Aggregate trọn vẹn | Mỗi khuyến mãi được lưu có đúng một phương thức; các tập quy tắc được lưu cùng nó |
| Số đếm chính xác | Số đếm quy tắc điều kiện / nguồn / đích luôn khớp với quy tắc thực sự được lưu |
| Toàn vẹn khi sửa | Cập nhật aggregate tạo, sửa và xóa quy tắc trong một transaction theo hình dạng mục |
| Toàn vẹn mã | Không có hai khuyến mãi còn sống trong một merchant dùng chung một mã |
4. Chân dung & Trường hợp dùng
| Chân dung | Mục tiêu trong feature này |
|---|---|
| Chủ cửa hàng / Quản lý | Dựng một chiến dịch giảm giá - chọn cơ chế, đích, và các quy tắc phân khúc nó |
| Nhân viên marketing | Soạn ưu đãi giới hạn thời gian (giờ vàng, ngày trong tuần, theo kênh) và rút lại qua trạng thái |
| Hệ thống (thanh toán tương lai) | Đọc một đồ thị khuyến mãi hoàn chỉnh, hợp lệ để áp tại điểm bán (bước tăng trưởng sau) |
Kịch bản chính: chủ cửa hàng tạo khuyến mãi "Mua 2 cà phê, tặng 1" - cơ chế BUY_GET, một phương thức PERCENTAGE giá trị 100 nhắm ITEMS với nguồn-tối-thiểu 2 và đích 1, một quy tắc nguồn (đồ uống đủ điều kiện) và một quy tắc đích (đồ uống tặng), cộng một quy tắc điều kiện giới hạn kênh dùng tại chỗ. Khuyến mãi, phương thức và cả ba quy tắc được lưu trong một lời gọi nguyên tử; số đếm quy tắc đọc lại đúng. Sau đó chủ cửa hàng sửa aggregate để bỏ quy tắc kênh và nâng giới hạn lượt dùng - tất cả trong một transaction.
5. Câu chuyện Người dùng
- Là chủ cửa hàng, tôi tạo một khuyến mãi, phương thức và mọi quy tắc của nó trong một request, để chiến dịch không bao giờ bị lưu dở.
- Là chủ cửa hàng, tôi chọn số tiền cố định hay phần trăm và nhắm nó vào dòng hàng, đơn hàng hoặc vận chuyển, để ưu đãi khớp với cái tôi đang quảng bá.
- Là chủ cửa hàng, tôi dựng deal mua-X-tặng-Y bằng cách đặt số lượng nguồn phải mua và số lượng đích được giảm, để các ưu đãi combo kinh điển khả thi.
- Là nhân viên marketing, tôi phân khúc một ưu đãi bằng quy tắc điều kiện, nguồn và đích, để nó chỉ kích hoạt với đúng giỏ hàng trên đúng kênh.
- Là nhân viên marketing, tôi rút một ưu đãi bằng cách chuyển trạng thái sang ngừng hoặc hết hạn, để nó dừng mà không bị xóa.
- Là chủ cửa hàng, tôi sửa quy tắc của một khuyến mãi đang có - thêm, đổi và bỏ - trong một lần lưu, để bảo trì là một bước nguyên tử duy nhất.
6. Yêu cầu Chức năng
| # | Yêu cầu | Tham chiếu URD |
|---|---|---|
| FR-1 | Một khuyến mãi, phương thức duy nhất của nó, và các tập quy tắc được tạo cùng nhau trong một aggregate nguyên tử | URD-PROMO-001 |
| FR-2 | Một khuyến mãi có nhiều nhất một phương thức | URD-PROMO-003 |
| FR-3 | Phương thức là FIXED hoặc PERCENTAGE, mang giá trị giảm | URD-PROMO-008 |
| FR-4 | Phương thức nhắm ITEMS, ORDER, hoặc SHIPPING | URD-PROMO-009 |
| FR-5 | Phương thức khai báo một phân bổ (EACH / ACROSS / ONCE) và có thể giới hạn số lượng được giảm | URD-PROMO-010..011 |
| FR-6 | Một khuyến mãi là STANDARD hoặc BUY_GET; phương thức mua-tặng khai báo số lượng nguồn-tối-thiểu và đích | URD-PROMO-007 · URD-PROMO-012 |
| FR-7 | Ba tập quy tắc phân khúc chiến dịch: điều kiện (khuyến mãi), nguồn và đích (phương thức), dùng lại mô hình quy tắc chung | URD-PROMO-013 · URD-PROMO-004 |
| FR-8 | Số đếm quy tắc điều kiện / nguồn / đích được denormalized và luôn chính xác khi quy tắc thay đổi | URD-PROMO-014 |
| FR-9 | Một khuyến mãi mang một mã duy nhất tùy chọn (không mã ⇒ tự động), một cờ stacking, và một cờ đã-gồm-thuế | URD-PROMO-015..016 |
| FR-10 | Một khuyến mãi mang khoảng thời gian hiệu lực, giới hạn lượt dùng và số lượt dùng đang chạy | URD-PROMO-017 |
| FR-11 | Một khuyến mãi đi qua trạng thái vòng đời, mặc định là DRAFT | URD-PROMO-018 |
| FR-12 | Cập nhật aggregate trộn quy tắc theo hình dạng mục (tạo / sửa / xóa) trong một transaction | URD-PROMO-019 · URD-PROMO-002 |
| FR-13 | Xóa một khuyến mãi lan truyền tới phương thức và mọi quy tắc đính kèm một cách nguyên tử | URD-PROMO-020 |
| FR-14 | Khuyến mãi, phương thức và quy tắc được cô lập theo merchant và xóa mềm | URD-PROMO-005 |
Toàn văn yêu cầu và tiêu chí chấp nhận nằm trong URD Định giá - PROMO. PRD này tham chiếu thay vì lặp lại.
7. Yêu cầu Phi chức năng
| Lĩnh vực | Yêu cầu |
|---|---|
| Tính nguyên tử | Toàn bộ đồ thị chiến dịch - khuyến mãi, phương thức, quy tắc điều kiện / nguồn / đích - là một transaction được-ăn-cả-ngã-về-không |
| Tenancy & phân quyền | Mọi thao tác cô lập theo merchant (x-merchant-id), xác thực (JWT hoặc basic) và gác bởi quyền khuyến mãi / phương thức / quy tắc |
| Kiểm tra hợp lệ | Một quy tắc được tạo trong một aggregate phải mang thuộc tính, toán tử và kiểu dữ liệu, nếu không cả thao tác bị từ chối |
| Nhất quán | Số đếm quy tắc denormalized được cập nhật trong cùng transaction với các quy tắc nó đếm |
| Độ chính xác | Giá trị giảm, số lượng tối đa và số lượng mua-tặng dùng độ chính xác thập phân (4 chữ số) |
| i18n | Tên và mô tả khuyến mãi là song ngữ ({ en, vi }) |
8. UX & Luồng
Bề mặt cấu hình cho chủ cửa hàng chọn cơ chế, đặt mã (hoặc để tự động), xác định cửa sổ hiệu lực và giới hạn lượt dùng, chọn cơ chế / đích / phân bổ của phương thức, nhập số lượng mua-tặng, và đính ba tập quy tắc. Việc sửa dùng lại cùng aggregate; trạng thái đưa chiến dịch qua vòng đời mà không cần xóa.
9. Dữ liệu & Miền
| Thực thể | Vai trò trong feature này |
|---|---|
Promotion | Chiến dịch - cơ chế, mã/tự động, stacking, đã-gồm-thuế, cửa sổ hiệu lực, giới hạn/số lượt dùng, trạng thái; giữ các quy tắc điều kiện |
PromotionMethod | Cơ chế duy nhất - giá trị cố định/phần trăm, kiểu đích, phân bổ, giới hạn số lượng được giảm, số lượng nguồn-tối-thiểu và đích mua-tặng |
Rule | Một điều kiện đa hình (thuộc tính, toán tử, giá trị, ưu tiên); gắn vào khuyến mãi (điều kiện) hoặc phương thức (nguồn / đích, phân biệt bởi ngữ cảnh) |
Chỉ mang tính khái niệm - schema đầy đủ và bất biến nằm trong mô hình miền Định giá. Quy tắc nguồn và đích của một phương thức là cùng một thực thể được phân biệt bằng một thẻ ngữ cảnh được lưu; toàn vẹn được đảm bảo trong service aggregate, không phải bởi ràng buộc cơ sở dữ liệu.
10. Phụ thuộc & Giả định
Phụ thuộc vào
- Mô hình quy tắc chung (URD-PROMO-004, cũng dùng bởi FARE) - quy tắc điều kiện, nguồn và đích dùng lại cùng hình dạng thuộc tính / toán tử / giá trị với logic AND.
- Commerce / Merchant - mọi khuyến mãi, phương thức và quy tắc đều theo phạm vi merchant.
@nx/core- mô hình khuyến mãi, phương thức và quy tắc, các cơ chế và hằng trạng thái.
Giả định
- Một khuyến mãi có đúng một phương thức; chiến dịch nhiều phương thức nằm ngoài phạm vi.
- Quy tắc nguồn và đích chỉ có ý nghĩa với cơ chế kiểu mua-tặng; khuyến mãi tiêu chuẩn thường chỉ dùng quy tắc điều kiện.
- Bộ tính lúc thanh toán tiêu thụ cấu hình này là một bước tăng trưởng riêng, sau này.
11. Rủi ro & Câu hỏi Mở
| Rủi ro / câu hỏi | Giảm thiểu / trạng thái |
|---|---|
| Chiến dịch dở dang khi thất bại (khuyến mãi không phương thức, hoặc có quy tắc mồ côi) | Toàn bộ đồ thị là một transaction nguyên tử - bất kỳ thất bại nào cũng rollback hoàn toàn |
| Số đếm quy tắc lệch với quy tắc thực sự lưu | Số đếm được denormalized và cập nhật trong cùng transaction với các quy tắc |
| Ý định sửa mơ hồ (thêm vs đổi vs bỏ một quy tắc) | Cập nhật aggregate theo hình dạng: không id tạo, id+trường sửa, chỉ id xóa |
| Hai khuyến mãi còn sống dùng lại một mã | Mã là duy nhất theo merchant trong số các khuyến mãi chưa xóa |
| Chủ cửa hàng mong giảm giá áp khi thanh toán | Ngoài phạm vi bước này - bộ tính chưa được đấu nối (URD-PROMO-006) |
12. Kế hoạch Phát hành & Tiêu chí Ra mắt
| Khía cạnh | Kế hoạch |
|---|---|
| Phase | P3 - PROMO trong danh mục feature URD |
| Triển khai | Mọi merchant; không cờ tính năng |
| Di trú | Không - bảng khuyến mãi / phương thức / quy tắc mới; không đổi dữ liệu fare/thuế hiện có |
| Tiêu chí ra mắt | Tạo aggregate lưu khuyến mãi + một phương thức + mọi tập quy tắc nguyên tử; số đếm đọc lại đúng; cập nhật aggregate trộn quy tắc theo hình dạng; xóa lan truyền; mã duy nhất theo merchant |
| Giám sát | Tỷ lệ lỗi tạo/cập nhật aggregate theo lý do (thiếu trường quy tắc, không có phương thức, xung đột mã) |
13. FAQ
Tạo một khuyến mãi có áp giảm giá khi thanh toán không? Không - bước này chỉ bàn giao bề mặt cấu hình. Bộ tính áp khuyến mãi khi định giá là một bước tăng trưởng riêng, sau này (URD-PROMO-006).
Một khuyến mãi có bao nhiêu phương thức? Đúng một. Cơ chế (cố định/phần trăm, đích, phân bổ, số lượng mua-tặng) đều nằm trên phương thức duy nhất đó.
Ba tập quy tắc khác nhau ở đâu? Quy tắc điều kiện (trên khuyến mãi) quyết định ai/khi nào đủ điều kiện; quy tắc nguồn (trên phương thức) quyết định cái gì phải mua; quy tắc đích (trên phương thức) quyết định cái gì được giảm. Nguồn và đích là cùng một thực thể quy tắc phân biệt bởi một thẻ ngữ cảnh được lưu.
Tôi sửa quy tắc của một chiến dịch thế nào? Gửi một cập nhật aggregate - quy tắc không id được tạo, quy tắc có id và trường được sửa, quy tắc chỉ có id được xóa, tất cả trong một transaction.
Điều gì xảy ra với phương thức và quy tắc khi tôi xóa một khuyến mãi? Chúng bị xóa lan truyền cùng nó trong một transaction - không để lại phương thức hay quy tắc mồ côi.
Một khuyến mãi không có mã nghĩa là gì? Nó chỉ tự động (auto-apply). Một mã, khi có, là duy nhất theo merchant trong số các khuyến mãi còn sống.
Tham khảo
- URD: Định giá - PROMO
- PRD cùng nhóm: Bộ máy định giá Fare & Thuế
- Module: Định giá - tổng quan + năng lực
- Tài liệu kỹ thuật: @nx/pricing · Promotion System · @nx/core