去年底我们在一家三甲医院落地食堂系统时信息科的同事问了一个很实际的问题优惠券、积分、科室签单这些功能听着像营销插件但落到系统层面账怎么算、钱怎么分、数据怎么对这三个问题没想清楚功能做得再花哨也是空中楼阁。这篇文章就从技术视角把好伙狮数字食堂这套精细化运营引擎里规则引擎、积分账户、签单分账三个模块的设计思路拆解一下供正在评估方案的信息科同行参考。一、优惠券的本质是一个规则引擎优惠券看起来简单但要做到定向发放、精准核销、自动结算底层必须是一个可配置的规则引擎。满减、折扣、兑换三种券型本质上是三种不同的计价规则而定向发放则是把用户画像、时段、场景等维度作为规则的触发条件。设计上通常把一张券抽象为几个核心字段券类型、门槛条件、优惠内容、适用人群、有效期、发放渠道。结算时订单信息进入规则引擎按优先级匹配可用券计算优惠金额再回写到订单。这样设计的好处是运营人员调整规则不用改代码只需要改配置。二、积分体系是一套独立的账户模型积分商城的技术难点不在发积分而在账要对得上。每一个积分都要有来源消费返分、活动奖励、去处兑换商品、兑换券、以及时间戳形成完整的流水。因此在系统设计上积分不是挂在用户表里的一个简单数字而是独立的账户体系每个用户有一个积分账户账户下挂着一笔笔可追溯的积分流水。消费产生的积分、兑换消耗的积分都走流水记录。这样既能防止积分凭空多出来也方便对账和审计。三、科室签单核心是一个分账模型科室签单从技术上看比前两者更复杂因为它涉及挂账和分账。签单消费的特点是先消费、后结算钱暂时不落到食堂而是挂到科室的应收账上。这里的关键设计是归集每一笔签单订单在生成时就打上了科室维度的标签后续的审核、对账、结算都围绕这个标签展开。审核环节是状态机——申请、待审、通过、驳回、已结算每个状态流转都有记录。月底对账时系统按科室维度聚合订单自动生成对账单。分账的底层则是把消费者—食堂的两方关系扩展成消费者—科室—食堂的三方关系。签单的账记在科室名下结算时再由科室统一支付。这种模型设计清楚之后签单、优惠券、积分才能在同一张订单里协同工作而不互相打架。四、几个容易踩的坑说了设计思路再说几个我们在落地时踩过的坑。第一个坑是并发。结算时券和积分的核销如果并发请求同时触发容易出现重复核销。解决思路是给券和积分账户加幂等控制同一个订单只允许核销一次。第二个坑是精度。金额计算如果直接用浮点数容易出小数位误差尤其是签单对账这种一分都不能差的场景。建议金额统一用分整数存储和计算。第三个坑是数据边界。优惠券、积分、签单的数据要和医院现有的HIS、财务系统打通接口标准和数据口径必须提前约定清楚否则后期对账又是一堆麻烦。总结一下优惠券、积分、签单这些营销功能落到系统层面本质是规则引擎、账户体系、分账模型三块硬功夫。方案评估时别只看界面好不好看多问问底层这几块是怎么设计的往往能看出厂商的技术成色。你们在评估食堂系统时最看重哪一块欢迎评论区交流。