Domů Procházet Nápověda
Přihlásit se
fa88
/
foodie-server
1
0
Rozštěpit 0
Soubory Úkoly 0 Pull Requesty 0 Wiki
Větev: master
Větve Značky
foodie-server
/
specs
/
008-promotion-coupon
/
checklists
/
requirements.md

requirements.md 5.5 KB
Trvalý odkaz Historie Surový

Checklist: 促销 + 优惠券系统 — 整体需求质量

Purpose: 实施前预检，确保 spec/plan/tasks 可直接进入编码 Created: 2026-06-01 Feature: 008-promotion-coupon Depth: Standard | Actor: Author (pre-implementation)

数据模型完整性

  • CHK001 — 6张表的 DDL 是否都有完整字段定义（类型、长度、默认值、NOT NULL 约束）？ [Completeness, Spec §Data Model]
  • CHK002 — promotion_activity_rule 表是否为每种促销类型（1~4）定义了清晰的字段使用映射（哪些字段有值、哪些为 NULL）？ [Clarity, Spec §Data Model]
  • CHK003 — promotion_coupon_rule 表的 is_mutex 字段是否明确标注了"商品券时此字段含义为何"（商品券是否需要互斥属性）？ [Ambiguity, Spec §Data Model]
  • CHK004 — promotion_user_coupon 的 expire_time 计算规则是否明确（receive_time + valid_days 天，含不含当天23:59:59）？ [Clarity, Spec §FR-010]
  • CHK005 — pos_order_promotion 表的 promo_detail（JSON）是否定义了每种促销类型的标准 JSON schema？ [Completeness, Gap]
  • CHK006 — 所有表的主键策略是否统一为 AUTO_INCREMENT？是否有表需要分布式 ID？ [Consistency, Spec §Data Model]

商家端功能需求

  • CHK007 — 促销活动创建后，状态从"未开始"变为"进行中"的时机是否明确（创建时根据 startTime 判断 vs 定时任务）？ [Clarity, Spec §FR-001]
  • CHK008 — "结束活动"操作是否可逆？结束后的活动能否重新激活？ [Gap, Spec §FR-005]
  • CHK009 — 折扣商品的"折扣区"名称是否需要存储？还是纯前端展示概念？ [Clarity, Plan §Key Design Decisions 1]
  • CHK010 — 优惠券创建时 remain_count 初始化为 total_count 的逻辑是否在 Service 层明确？ [Completeness, Tasks T025]
  • CHK011 — 优惠券"下架"后已领取的券是否仍可使用？此行为是否在 spec 中明确？ [Edge Case, Spec §FR-009]
  • CHK012 — 活动时间范围是否允许跨年或超长周期（如1年）？是否需要限制？ [Gap]
  • CHK013 — 同一门店能否同时创建多个同类型的促销活动（如两个满减活动同时进行）？ [Ambiguity, Spec §互斥规则]

用户端接口需求

  • CHK014 — 领券接口（FR-012）的并发控制是否定义？多人同时领取最后一张券时的处理策略？ [Edge Case, Gap]
  • CHK015 — 查询门店可领券列表接口（FR-011）是否需要分页？ [Completeness, Plan §UserPromotionCouponController]
  • CHK016 — "我的优惠券"接口（FR-013）是否需要返回券对应的门店名称？ [Completeness, Gap]
  • CHK017 — 领券后有效期计算是否考虑了"当天剩余时间"（如23:50领券，valid_days=1，过期时间是明天23:59还是今天结束）？ [Ambiguity, Spec §FR-010]
  • CHK018 — 用户券状态"已过期"是实时查询判断还是有定时任务批量更新？ [Clarity, Gap]

互斥规则与叠加

  • CHK019 — 互斥规则"满减/折扣/第二份半价三选一"是否覆盖了门店同时有多个同类型活动的场景（如两个满减活动，选哪个）？ [Coverage, Spec §互斥规则]
  • CHK020 — "新客立减"的"新客"定义是否明确（首次下单？首次在该门店下单？注册后N天内？）？ [Clarity, Spec §FR-004]
  • CHK021 — 同享券和互斥券的叠加逻辑是否在算价接口 Response 中体现（互斥券选中后促销如何变化）？ [Consistency, Plan §UserPromotionCalcController]
  • CHK022 — 商品券作用于指定商品时，如果订单中有多个该商品，是只优惠一个还是全部优惠？ [Ambiguity, Spec §FR-008]

API 设计一致性

  • CHK023 — 商家端 API 的分页参数格式（page/size vs pageNum/pageSize）是否与项目现有 Controller 一致？ [Consistency, Plan §ShPromotionActivityController]
  • CHK024 — 用户端接口路径前缀 /app/userPromotionCoupon 是否与项目现有用户端接口路径风格一致？ [Consistency, Plan §UserPromotionCouponController]
  • CHK025 — 所有接口的错误响应格式是否统一（code/msg/data 结构）？ [Consistency, Gap]
  • CHK026 — 算价接口（POST /calculate）是否需要用户登录鉴权？商品价格由前端传入还是后端从数据库查？ [Completeness, Plan §UserPromotionCalcController]

范围与边界

  • CHK027 — spec 中"不做"的清单（爆品、买赠、店外发券等）是否明确标注为"不做"而非"延后"？避免实施时混淆。 [Clarity, Spec §foodie 范围裁剪]
  • CHK028 — pos_order 现有优惠字段（mdSalesReduction 等）在本期是否仍需写入？还是只写 pos_order_promotion 明细表？ [Ambiguity, Spec §Assumptions]
  • CHK029 — 旧代码（SalesPromotion、VipQuanyi）的数据库表是否保留？是否有数据迁移需求？ [Gap, Spec §旧代码处理]
  • CHK030 — PromotionUserCoupon 实体在 Phase 2 创建但无 Service，Phase 5.5 才补。是否有 Phase 间数据层断裂风险？ [Dependency, Tasks T007 → T039]

可测试性

  • CHK031 — Success Criteria（SC-001~005）是否都可通过 Postman + 手动操作验证？还是有需要自动化测试覆盖的？ [Measurability, Spec §Success Criteria]
  • CHK032 — 算价接口的 Response 示例是否覆盖了满减 + 折扣 + 新客立减 + 优惠券全部叠加的场景？ [Coverage, Plan §算价接口 Response]
  • CHK033 — 是否有测试数据准备计划（哪些门店/商品/活动需要预创建）？ [Gap]