从单店到连锁：解耦方法的探索与实践
一、连锁业务复杂度的来源
一个有线下门店业务的商家，在做业务扩张时，考虑到扩张的成本，会寻找一套可复制的经营方式，通过连锁的模式进行规模化扩张。
不同行业对于规模化的应用也有所不同：对于零售商家，单个门店的人流量和仓储能力都是有限的，更多的门店往往意味着更大的人流和更快的物流；而对于美业这样重线下服务的商家，单个门店能覆盖的服务范围是有限的，更多的门店意味着更大的服务范围和更多的客户；即便对于单纯做网店的商家，也可以利用合伙人的能力来帮助自己更快的发展。
在从单个门店到多个门店的过程中，商家的管理和运营都会变得更加复杂，怎么对门店的商品、店铺装修等进行统一管理，怎么发挥总部的优势给底下的门店带流量，怎么去激励业绩不好的门店等等。对应的在技术侧，架构也需要演进、迭代来支撑越来越复杂的业务，从前只需要考虑一个门店，现在需要考虑多个，考虑品牌下总部和门店、门店和门店间的关系等等。
以上是对连锁业务复杂度由来的简单介绍。复杂业务如果没有得到相应的设计和处理，就会带来痛点，这篇文章聚焦在其中一个比较常见的痛点上，聊聊这个痛点是如何产生，以及我们如何解决。
二、连锁业务开发的痛点
连锁的很多功能都需要深入到具体的业务去设计和开发，在给一个业务去迭代一个连锁的能力时，都需要对这块业务原本的逻辑有一个深入和全面的理解后才能上手，比如商品库、跨店核销、组合卡适用多门店等等。
经历了这么多项目后，会发现有一些共同的痛点： 1、系统不易理解：开发同学往往会发现原有系统设计和代码实现逻辑混乱，不知从何下手 2、代码不好修改：调整一个连锁的逻辑，会影响到原有一些很底层的功能，影响面很大 3、维护和部署不方便：改动一个连锁的功能，需要发布核心应用
整体而言就是在涉及到连锁解决方案的需求时，研发的生产力会比较低。
于是就在想，有没有办法通过一些优化和设计，来让连锁的开发同学： 1、更快速的理解一个业务，做出合理的技术设计 2、更舒服的编写代码 3、更安全的发布一个新功能
在探索和实践这件事情时，大致的思路是这样： 1、找一个具体的连锁场景，分析其业务逻辑：这里我找的典型场景是商品，考虑到大家对商品都比较了解； 2、分析下现在是怎么实现的？ 3、现在这样的实现方式，会有哪些问题？ 4、怎么去优化它？
三、连锁业务现状
3.1 商品业务场景
这里用一个多维表格，描述下一个简单的 B 端商品业务流程，包含：商品创建、上下架、查看和编辑。
横轴是业务场景，纵轴是组织类型，中间的内容，是这些业务场景在对应的组织类型上会有什么样的表现：
3.2 现在的实现
以编辑商品为例，现在的实现大致分两步： 1、更新商品，发送商品变更消息 2、消费者收到消息，处理变更信息，更新分店商品看起来是很清晰，但实现上还是有些问题，下面是伪代码：
编辑商品
updateItem(req) {
// 前置校验：参数校验、权限校验、编码重复性校验等等
validate(...);
// 如果是总部更新
if(updateByHeadQuarter(...)) {
// 更新总部商品
...
}
// 如果是门店更新
if(updateByStore(...)) {
// 只允许更新部分属性
...
}
// 发消息
sendMsg(...);
}消费者监听消息，更新门店商品信息
handle(msg) {
// 根据不同的商品事件类型，走不同的处理动作
switch (msg.goodsEventType) {
// 新建商品
case NEW:
...
// 更新商品
case UPDATE:
processUpdateEvent(msg);
// 上下架
case TAKE_UP_DOWN:
...
// 其他事件类型，不一一列举
case XXX:
...
}
}
processUpdateEvent(msg) {
// 如果是总部更新，则同步信息到门店
if (updateByHeadQuarter()) {
// 查询总部下所有门店
getAllStore(...);
// 更新这些门店的商品信息
updateAllStore(...);
}
}这样的实现有什么问题呢？大家可以先想一想。 3.3 存在的问题
刚刚提到的所有业务功能，都是由商品服务提供的，把他们都平铺出来，就是这样：
讲具体些，以上面的商品编辑为例，当前的实现存在的问题有：
1、耦合 通用的底层逻辑和连锁逻辑耦合在一起，比如门店能更新哪些商品属性，这个逻辑和通用的更新商品逻辑耦合在了一起，如果后续需要调整这个逻辑，比如允许门店自己修改商品条码，那就会动到通用编辑商品的代码；
2、忙碌的消费者 代码里通过一个消费者，来监听和处理所有的商品事件，而把总部商品同步到门店，这本身是一个独立的逻辑，却被揉在了这个消费者里去实现，本质上是因为大家对这个服务的定位有关，大家觉得这个服务就是要把所有的商品能力都实现了，所以就会写出这样一个忙碌的消费者；
3、能力缺少复用 无论是编辑单个商品，还是批量编辑门店商品，逻辑上应该是一致的，但是我们却看到现在是两份代码，代码没有任何复用；
四、解耦方法的探索与实践
4.1 优化思路
基于以上分析，再结合一些常用的设计模式和原则，于是有了以下的优化思路：
1、开闭原则（OCP） 能不能让允许门店更新哪些属性，和商品通用编辑能力隔离、解耦，不互相干扰；
2、单一职责（SRP） 能不能把「总部商品信息同步到门店」，这个逻辑单独抽离，独立成一个消费者，就只专心做这一件事情；
3、让商品更专注于自己的领域 能不能让商品不太去关注总部、门店这样的连锁组织关系，让它去提供一套对所有店铺通用的商品能力，和店铺的耦合，就只是弱耦合一个店铺ID。
基于上面的「业务场景-组织关系」的二维矩阵，我们发现可以把业务场景做进一步的抽象和拆分，分成： 单店能力 + 连锁能力
划分的标准很简单，如果一个能力是单店商家就需要有的，那就属于单店能力，如果是连锁商家（两个或两个以上门店的商家）才需要的能力，那就属于连锁能力。
我们来看看如果按照上面的划分标准，之前的场景可以抽象出哪些能力，这些能力属于单店能力还是连锁能力：
4.2 部署方式
把商品能力拆解为连锁能力和单店能力后，在部署方式上也进行了对应的设计，来支持业务的快速发展和系统的稳定：
带来的好处是： 1、代码解耦 比如门店能更新哪些商品属性，这个属于连锁能力，需求有调整时只需修改发布 mei-chain，不会修改 mei-goods，不影响单店逻辑； 2、部署隔离 就算 mei-chain 挂了，也不影响单店操作场景，只影响连锁场景。 举个例子，如果 mei-chain 所有实例都下线了，那么总部和门店还是可以创建商品，但是如果总部编辑了商品，同步信息给门店时会失败，等 mei-chain 恢复后重新启动消费者，把消息消费了，业务和数据即可恢复正常； 3、职责单一明确 通过这样的部署方式，促使开发时会进行更细粒度的思考，比如总部-门店商品信息同步的事情属于连锁能力，就该由 mei-chain 负责，通过单独一个消费者实现，而不是在 mei-goods 写一个庞大的消费者。
图中画了一个 api 层，这里想展开聊一下。
其实本来 api 层我画的是虚线，因为 mei-goods 和 mei-chain 本身都可以对外提供 api 接口，不管是 rpc 还是 restful，都可以提供，这样 api 层也就只是一个概念意义上的存在了。
之所以画成实线，一方面是因为对于前端来说 api 层是很真实的存在，前端同学不关心接口底层是由 mei-goods 还是 mei-chain 实现，只对接 api；另一方面，我们可以在 api 层做一些聚合类的操作，比如对于商详页，我们除了基础的商品信息，还需要聚合一些活动信息，比如这个商品是不是参与了秒杀、拼团、体验价，还需要聚合库存等等，如果没有单独拎出来，那我们就很容易把这些逻辑也放到 mei-goods 或者 mei-chain 来实现，这样就又造成了污染。
我们可以提供一些大而全的接口，但是我们要基于一些小而精的接口来提供，这种思路是和最近常常被提起的 Serverless 背后的理念是一致的。每个领域都会单独提供自己领域内的接口，然后再在这上面做一些胶水层，进行数据的聚合，现在我们可能是在后端应用做，以后我们可以在 node 层做，甚至可以在 Serverless 架构中的云函数里做。
4.3 谁来开发
常规来说，连锁逻辑（mei-chain）由连锁团队开发，单店逻辑（mei-goods）由营销、店务团队开发。
实际情况常常是资源紧缺的，比如营销店务同学业务很忙，则连锁团队即开发 mei-chain 又开发 mei-goods，反过来，连锁同学很忙，那营销店务同学也可能即开发 mei-chain 又开发 mei-goods。
其实架构的设计终究还是为业务服务的，由哪个团队、由谁来开发哪个应用，这个并不是特别重要，重要的是通过这样一种架构的设计，我们能够： 1、快速支撑业务的调整和发展 2、提高系统稳定性 3、引导开发和产品思考
最后一点似乎有点狂，一个架构的设计还能引导产品思考？其实这点也是在组内分享的时候，产品同学的共鸣给我带来的启发。通过对连锁和单店的解耦，开发同学会自然的将连锁、单店的逻辑分开考虑，不耦合在一起，而开发同学在和产品同学的频繁接触过程中，会反过来去推动产品，也这样去思考问题。
正如 Bob 大叔在《架构整洁之道》里说的，软件架构的设计，会影响软件系统的全生命周期：
软件架构设计的主要目标，是支撑软件系统的全生命周期，设计良好的架构可以让系统便于理解、易于修改、方便维护，并且能轻松部署。 软件架构设计的终极目标，是最大化程序员的生产力，同时最小化系统的总运营成本。 —— 《架构整洁之道》
4.4 小程序直播的落地实践
我们在小程序直播项目里第一次采用了这样的设计。
对于直播而言，理论上每个具有经营能力的组织都可以发起直播，但是有能力去把直播这件事做好的往往只有总部，所以我们既要支持有能力直播的门店自己发起直播，又要让总部可以给门店去直播带货。很自然的我们把创建直播间这类能力归为单店能力，把和总部统一直播相关的，诸如批量应用直播间、批量配置直播间浮窗等，归为连锁能力。
实践中印象比较深的，是由于进行了拆分，后端给前端提供了更低粒度的接口，并且这次后端也没有在 api 层进行聚合，有些业务需要前端去进行聚合，这和以往一个接口对应一个页面的前后端配合模式不太一样，也算是一种尝试吧。
4.5 这里说的单店能力、连锁能力和 DDD 的关系？
这也是在组内分享时大家讨论的最深的一个问题。
在思考这个问题前，我觉得需要先思考另一个问题 —— 店铺域和其他领域的关系。
每个领域都有自己负责的那块业务，这些业务大多都会关联一个店铺ID，虽说对于一件商品、一个营销活动、一个客户，它们本身并不一定需要和店铺有什么关系，但是考虑到实际的电商经营场景，这些商品、营销活动终究要归属到某个店铺上。
但是其他领域在进行设计的时候，出于聚焦也好，出于减轻思考压力也好，并不会把店铺摆在台面上来讨论，因为我们默认一件商品、一个营销活动、一个客户天然就是要挂在一个店铺上的。我们更多的是聚焦在商品、营销活动、客户域自身应该有哪些业务属性和动作。
而这个时候如果把一些连锁的场景考虑进来，就会让思考变得复杂，这时候我们可以做一个减法，只考虑单门店商家，无需关心操作的是总部，还是门店，还是合伙人，还是其他店铺角色。从业务的角度思考，连锁商家都是从单门店做起来的，在探索和实践出一套可复制的经营之道后再进行规模化，把整套方法应用在每个门店上，对应到技术上，最后的操作还是要落在每一个门店上的，在基于单门店场景构建单店能力后，我们同样可以继续基于这套单店能力，去继续搭建更复杂的连锁能力，而这个时候，我们只需要去思考连锁场景，因为单店的我们已经解决了。
回到问题本身，DDD（Domain Driven Design，领域驱动设计） 是一套解决复杂业务问题的方法，对于已经很复杂的业务，如果我们同时考虑单门店和连锁的场景，就会让业务变得更加复杂，加大了 DDD 实践起来的难度，这时候我们对业务场景划分了边界，先聚焦在单门店的场景，再聚焦在连锁的场景，把他们分成两个独立的领域去解决，比如在这个例子里，我们把商品分成单店商品领域和连锁商品领域，他们合起来共同为有赞的商品领域提供解决方案。
4.6 边界
最后想探讨一下这套设计的局限性。
有一些业务需求在单门店商家里是不存在的，比如绝大多数的供应链场景、财务场景，比如库存调拨、门店要货、资金分润等等，这些场景只会发生在连锁的商家，那也就不需要像上面那样按照单店、连锁的维度进行划分了。
五、总结
这篇文章主要介绍了连锁业务的痛点，并且分析了痛点的来源，以及通过结构化分析进行解耦的探索和实践，中间也穿插了一些自己对于架构设计、DDD、Serverless 的一些思考和看法。希望通过这篇文章，能为读者在解决复杂业务上提供一些参考价值。