业务架构 · 总览

_context-map

业务架构以代码为锚:文档头里的四端签名一变,保鲜闸就逼人回看这份设计。

版本
0.7.0
真相源
true

真相源:.claude/arch/business/_context-map.md · 本页是它的构建产物,改内容改那份文件、重新构建即更新

arch Context Map(DDD 跨限界上下文关系图)

记录业务域(bounded context)之间的依赖方向与集成模式(防腐层 / 共享内核 / 顺从)。跨域数据流的单一真相源。
本文件为骨架,随各域 Stage 3 固化逐步补全。

跨域关系(已固化部分)

customer ──下单(skuId+quantity)──> ecommerce/order ──支付编排──> (pay-common 网关)
                        │
                        │  ① 客户预约触发(service 订单支付后:我的-待预约 → reserve 页选址+期望时间)
                        ├──dispatch-reserve-create 预建工单(R3-b:一次提交=一张工单挂 N 槽,可跨订单 → 派生 dispatching)──> ecommerce/dispatch
                        │        ※ ② settle 唯一受控反向回写四费(order-settle-update)
                        │           已随费用体系物理拆除整条消失(2026-08-14 裁定一) ⇒ order↔dispatch 现为纯单向
                        │
                        ├──③ order-self-read 两级 JOIN(order_item_node → dispatch_item_node 活明细 → dispatch_base 非关单) + 子查询读 dispatch_visit_node 6 态计数派生 fulfillStatus(只读)──> ecommerce/dispatch
                        │
                        ├──④ 客户自助取消:dispatch-self-cancel-update 本人守卫作废活工单(活跃三态 + supersededAt CAS)──> ecommerce/dispatch
                        │
                        ├──⑤ 下单锁券/核销/算抵扣 + 退款侧归还券(S3 全退返券 / S4 破门槛撤券,二者互斥)
                        │      (order 为券状态唯一驱动方,coupon 域自身/admin/前端永不直写)──> ecommerce/promotion/coupon
                        │
                        └──读──> ecommerce/{spu,sku}(商品快照,spu 已固化 ecommerce/spu/ARCH.md)

上门地址所有权:v0.3.0 从 order_base 迁 dispatch_base(customer_address_node ──reserve 预约冻结──> dispatch)

集成模式登记

上游 → 下游模式说明
ecommerce/order → pay-common顺从(Conformist)订单顺从微信支付网关契约,snapshot 落库防漂移
ecommerce/order → ecommerce/dispatch顺从(Conformist)+ 客户预约触发service 订单支付后客户经 dispatch-reserve-create 预建工单(读 order paid+service+本人守卫),dispatch 顺从 order 快照。★反向通道已归零(2026-08-14 裁定一 · 费用体系物理拆除)★:原「唯一受控反向 = order-settle-update 回写四费」的云函数、admin 原子(dispatch.api.ts orderSettle)、四费 8 列全部物理删除 ⇒ dispatch 域对 order 既无 server 直写、也无 UI 层桥接写。机制真相源 = ecommerce/dispatch/ARCH.md §6.2 与 ecommerce/order/ARCH.md §2.1(本表只登记边的消失,不复述设计)
ecommerce/order → ecommerce/dispatch反向读(fulfillStatus 派生)已换轴(2026-08-14 B3-a):order-self-read 两级 LEFT JOIN(order_item_node → dispatch_item_node 活明细 supersededAt<=>NULL → dispatch_base 非关单)+ 相关子查询读 dispatch_visit_node 6 态计数(cntTotal/pending/serving/done/partsmissing/visitfailed)派生客户履约阶梯 fulfillStatus,只读不写;上门地址所有权 v0.3.0 迁 dispatch_base
ecommerce/order ↔ ecommerce/dispatch★v4 三层模型:集成边整体换轴(★2026-08-14 R3-b 已完成·现役★)★现役 = 一张工单含多 SKU 多数量且可跨订单 ⇒ JOIN 轴已由 dispatch_base.orderItemId 换至 dispatch_item_node(服务项 = 1 次服务 = 1 配额槽),订单归属由 FK 变为 JOIN 派生dispatch_item_node.orderItemId → order_item_node → order_base),dispatch_base 与 order 自此无直接 FK(两旧列已停写、行锚已 DROP)。跨域影响三项均已落地:① 反向读族① 三家(order-self-read / order-stats-read / order-review-create)已 lockstep 换轴(B3-a);② 退款域 activeDispatchCount 三家闸 左半臂已改数活服务项(R3-b,与停写同窗;右半臂「已交付槽数」自 R2 起即在服务项表);③ 配额单位已由「订单行」改为「」。仍未做(勿据本行推断全绿):族② 活跃态判据下沉(B3-b,读侧阶梯仍读 dispatch_base.supersededAt)/ admin 读侧 fan-out(代表明细过渡窗口已开)/ markItemsFulfilled 按槽精选(带电债)。机制真相源 = ecommerce/dispatch/ARCH.md §2.4/§2.5(本表只登记跨域边存在性,不复述设计)
ecommerce/order → ecommerce/dispatch运维自愈跨域写(非业务对接·三臂)order 域定时器 order-payment-reconcile-update(cron 5min)反向 UPDATE dispatch 两表:① F54 releaseOrphanSlot(close 崩溃窗补释放活跃槽);② ⑦-v4 healOrphanActiveItem(明细活而工单废);③ **⑦-v4b scanHeadlessDispatches/healHeadlessDispatch(2026-08-14 R3-b 新增:工单活而零活明细 = 无腿工单,5min 缓冲后作废;是旧锚 DROP 的硬前置——DROP 后 1062 兜底消失,本臂成唯一自愈通道)。三臂均不表达业务语义、不驱动状态机,只在崩溃窗后拉回一致;登记于此仅因物理上是跨域写**(不登记 = 读 dispatch 文档者会误以为该表只由 dispatch 域自己写)。真相源 = ecommerce/dispatch/ARCH.md §6.2′
customer → ecommerce/dispatch客户自助反向触点客户经 dispatch-self-cancel-update 作废本人活工单:行级 authInfo.userId + 归属守卫 + 仅 orderStatus=paid 可撤 + supersededAt CAS 抢锁 + 连带作废活 visit(dispatch-self-cancel-update/service.js);订单回「待预约」桶可重新预约
ecommerce/order → ecommerce/promotion/coupon聚合根写守卫(order 为券状态唯一驱动方,coupon 域自身云函数 / admin / 前端一律永不直写)正向(下单链路):order-preview-read 满门槛筛可用券 + 权威算价抵扣;order-create 锁券(lockCouponForOrder CAS)+建单+绑定 orderId+锁失败补偿(closeOrderById/COUPON_LOCK_FAILED)+免单即时核销(markOrderPaidFree+redeemCouponByOrder);reconcile 券结算兜底(scanLockedCoupons 按订单态 redeem/release)。反向(退款链路,v0.3.0 补):券归还有且仅有两条互斥路径——S3 全退返券(used→unused,整单退光) 与 S4 破门槛撤券(locked|used→unused,非全退且保留品跌破门槛,订单仍存活,2026-08-06 P5-B 新增),二者均落 applyRefundAggregationCore 三家(pay-common orderService ∥ order-item-refund-update ∥ reconcile)NS-SERVER-0139 字节等值共同段;券侧台账 couponRollback/couponRevoke 由 reconcile ⑪/⑮ 双向 NOT EXISTS 互斥补写。**机制唯一真相源 = ecommerce/order/ARCH.md §4.8「S3 全退返券 / S4 破门槛撤券」**,coupon 域只声明「券终态的系统级例外存在」并指针到此(I2 防第二真相源)。写 coupon_customer_node 状态 unused→locked→used/released,退款侧可从 locked/used 单向回 unused
ecommerce/order → ecommerce/{spu,sku}防腐层 ACL + 快照order-create JOIN 商品三表双上架校验 + 快照冻结(详见 ecommerce/order/ARCH.md §6.1)
更多关系随域固化补入。