26 一月 2026
在平台业务中，保证金是平台对商家风险兜底的核心工具。
当同一个商家有多家店铺时，保证金的收取逻辑如下：
平台政策规定保证金应根据店铺数量缴纳。
通常第一家店金额较高，后续每家店金额较低。
比如：首家店收 2 万元，后续每家店收 1 万元。
在线下实际执行时，会出现对特定店铺进行优惠。
例如：第 3 家店减免。
当平台认定某些店铺违反规则时，会对保证金进行追加。
最开始模型设计得比较简单。
只记录了每个商家、每个店铺的保证金应收和实收。
但随着业务的发展，以上业务特征逐渐暴露出模型的局限性。 最终引发了严重的清算问题。
某商家下有三家店：
第 1 店：缴纳 2 万元
第 2 店：缴纳 1 万元
第 3 店：因特殊政策优惠，仅缴纳 5000 元
当第 1 家店（2 万）退出时，应退金额是多少？
这个看似简单的问题，在实际业务中却引发了巨大争议。
不同业务人员给出了三种截然不同的答案：
第 1 店对应 2 万，退出就退 2 万。
首店退出后，第 2 店变成首店。
按新阶梯，第 2 店应收 2 万。
实际只缴 1 万，需补缴 1 万。
所以只能退 1 万。
3 店共缴 3.5 万。
退出 1 店后，剩余 2 店按阶梯应收 3 万（2 万+1 万）。
所以应退 5000 元。
三种答案都有道理，却无法达成共识。
这个案例暴露出旧模型存在的两个核心问题：
| 维度 | 业务规则 | 系统实际记录 | |------|---------|-------------| | 定义 | 保证金按店铺数量计算 | 每家店应收多少钱 | | 范围 | 该商家当前应缴保证金额度 | 每个店的保证金是多少 |
1. 逻辑偏离
这种记录方式将后续逻辑带偏到"每个店的保证金是多少"。
导致退出场景下出现严重歧义。
2. 规则缺失
更关键的是：旧模型未约定店铺退出时阶梯标准如何重新计算。
这使得"以当前在网店铺数为准"这一原则，在退出场景下无法落地执行。
第 3 店因特殊政策优惠，仅缴纳 5000 元（假设标准应为 1 万元）。
系统只记录了 "第 3 店应收 5000" 这个结果。
| 缺失项 | 说明 | |--------|------| | 优惠金额 | 5000 元（标准 1 万 - 实收 5000） | | 优惠原因 | 为什么优惠？ | | 优惠权属 | 针对第 3 店？还是整个商家？ |
这种 信息隐含化 导致退出场景下产生更大的争议。
由于缺乏优惠/追加的明细记录和绑定关系的明确约定：
❌ 系统无法追溯原始决策依据
❌ 清退时，该"保留"还是"取消"这些额度
❌ 全凭人工经验判断
新模型将"保证金额度"与"账户余额"分离管理。
系统根据规则计算的保证金额度。
始终基于"当前在网店铺数量"与"阶梯标准"。
并叠加任何优惠或追加额度。
商家实际缴纳的保证金。
保证金额度 = 在网店铺数 × 保证金标准 + 优惠记录 - 追加记录
1. 以商家为单位计算
保证金额度是商家整体的概念。
而非每个店铺的简单累加。
2. 实时动态计算
当店铺数量变化时，系统自动重新计算保证金额度。
3. 退出时重算规则
店铺退出后，系统自动按剩余店铺数重新计算阶梯水位。
店铺入驻时，不再只记录"应收金额"。
而是完整记录：
优惠金额（优惠了多少，优惠原因）
追加金额（追加了多少，追加原因）
记录时间、操作人、审批流程
每笔优惠或追加必须明确绑定类型：
店铺绑定
针对特定店铺的激励优惠或风险追加。
随店铺生效/失效。
商家绑定
针对商家整体实力的减免或加收。
跟随商家，不随店铺。
根据剩余店铺数量，按阶梯标准计算基础保证金额度。
系统直接按阶梯规则计算，无需识别具体哪家是首店/续店。
根据绑定属性，叠加或取消优惠/追加记录：
绑定在该退出店铺：该优惠/追加同步取消
绑定在商家或绑定在其他店铺：继续保留叠加
最终应退/应补 = 账户余额 - 重算后的保证金额度
旧模型的核心问题是实现与模型脱节：
业务模型中有"保证金额度"的概念
但实现只记录了"店铺应收金额"
丢失了核心概念
业务规则没有明确描述。
只是在制定业务规则的人员心中，导致实现没有依据。
DDD 原则：领域模型是系统的核心，实现必须忠实地反映领域模型。
"优惠"在旧模型中是隐含的，只记录结果"应收 5000"。
显式化过程：
| 隐式概念 | 显式建模 | |---------|---------| | 店铺应收金额 | 店铺应收实体（标准金额、优惠金额、实收金额） | | 优惠归属 | 绑定属性值对象（店铺绑定/商家绑定） | | 优惠原因 | 优惠记录实体（金额、原因、时间、操作人） |
| 模糊表达 | 精确化表达 | |---------|-----------| | "保证金按店铺数量计算" | 保证金额度 = 在网店铺数 × 阶梯标准 + 优惠记录 - 追加记录 | | "多退少补" | 最终应退/应补 = 账户余额 - 保证金额度 |
领域模型应该使用通用语言（Ubiquitous Language）。
精确的概念定义是消除歧义的基石。