门店、商户与全渠道业务架构

该项目对门店、商户、供应商和服务范围等基础信息进行统一建模，使网站、App、运营后台和开放接口遵循一致的业务规则。

我在 2020—2022 年参与这部分系统的设计和演进。表面上，它像是维护门店资料的后台；实际上，一条基础数据可能同时影响商品展示、门店搜索、到家配送、供应商管理和运营操作。

企业名称及内部规则已经隐去，下面用几个实际问题说明我做了什么。

领域边界

“门店”“商户”“供应商”“柜台”在日常交流中很容易被混着使用，但在系统里不是一回事。

一个商户可以经营多个门店；一个门店可能关联不同柜台和服务范围；供应商又有自己的合同和生命周期。如果系统为了省事共用一个编号，后续就可能出现权限给错、数据关联错误，甚至关闭一家门店时误伤整个商户。

我的第一项重要工作，就是把这些对象的身份、关系、生命周期和负责方梳理清楚，形成团队共同使用的业务模型。

职责与关键工作

我负责相关系统的架构设计与持续改造，关键工作包括：

• 建立清楚的业务边界。 区分门店、商户、供应商、柜台和服务范围，定义它们怎样关联、由谁维护、何时生效或失效。
• 统一多渠道规则。 把原本重复写在 Web 和 API 入口里的校验、权限和状态规则放到共享服务中，让后台、接口、批处理和修复工具使用同一套逻辑。
• 完善位置与服务范围能力。 统筹经纬度、行政区域、配送半径、多边形范围和营业状态等条件，使系统不仅给出结果，还能说明门店为什么可服务或不可服务。
• 规范批量修改和数据修复。 要求先预演、估算影响范围，再小批量执行并保留检查点和前后对比，降低一次操作改坏大量数据的风险。
• 把人工干预纳入系统。 为紧急运营调整设计权限、原因、有效时间和审计记录，既允许快速处理问题，也避免人工操作绕开所有规则。

这些工作把分散的功能整理成了可复用的平台能力，并让后续需求能够建立在同一套基础数据和规则之上。

服务范围判断示例

用户输入地址后，系统不能只找“距离最近”的门店。它还要考虑地址属于哪个区域、门店是否营业、配送范围是否覆盖、是否存在临时运营调整等条件。

过去如果网站、App 和运营工具分别实现这些判断，就可能出现同一个地址在不同渠道得到不同答案。

项目将判断规则集中到统一服务：各渠道提交地址和业务场景，服务返回可用门店，同时记录采用的规则。出现异常时，运营人员能够区分坐标错误、配置问题与业务规则影响，减少反复试验式排查。

批量数据变更的安全控制

门店主数据经常需要批量导入或修正。一条脚本如果条件写错，可能一次影响成千上万条记录。

因此，我把修复脚本也当成正式软件管理：执行前先做 dry run，只显示将要修改的数量和样例；正式执行时拆成小批次，记录进度；执行后对比关键数据。如果中途失败，可以从检查点继续，也有回滚或补偿办法。

这项改造将依赖个人谨慎的操作，转化为团队可以重复执行、过程可检查的安全流程。

结果与架构价值

经过这些改造，门店和商户数据的含义更清楚，多渠道行为更一致，位置类问题更容易解释，批量变更也更可控。

原本几个系统各写一遍的业务规则被收拢成统一服务，运营人员那边也保留了可审计的使用与纠错入口。

架构原则是通过统一规则保证多渠道一致性，同时为必要的业务例外保留明确、受控的处理入口。