从单店到连锁：解耦方法的探索与实践

发表于 3年以前 | 总阅读数：404 次

一、连锁业务复杂度的来源

一个有线下门店业务的商家，在做业务扩张时，考虑到扩张的成本，会寻找一套可复制的经营方式，通过连锁的模式进行规模化扩张。

不同行业对于规模化的应用也有所不同：对于零售商家，单个门店的人流量和仓储能力都是有限的，更多的门店往往意味着更大的人流和更快的物流；而对于美业这样重线下服务的商家，单个门店能覆盖的服务范围是有限的，更多的门店意味着更大的服务范围和更多的客户；即便对于单纯做网店的商家，也可以利用合伙人的能力来帮助自己更快的发展。

在从单个门店到多个门店的过程中，商家的管理和运营都会变得更加复杂，怎么对门店的商品、店铺装修等进行统一管理，怎么发挥总部的优势给底下的门店带流量，怎么去激励业绩不好的门店等等。对应的在技术侧，架构也需要演进、迭代来支撑越来越复杂的业务，从前只需要考虑一个门店，现在需要考虑多个，考虑品牌下总部和门店、门店和门店间的关系等等。

以上是对连锁业务复杂度由来的简单介绍。复杂业务如果没有得到相应的设计和处理，就会带来痛点，这篇文章聚焦在其中一个比较常见的痛点上，聊聊这个痛点是如何产生，以及我们如何解决。

二、连锁业务开发的痛点

连锁的很多功能都需要深入到具体的业务去设计和开发，在给一个业务去迭代一个连锁的能力时，都需要对这块业务原本的逻辑有一个深入和全面的理解后才能上手，比如商品库、跨店核销、组合卡适用多门店等等。

经历了这么多项目后，会发现有一些共同的痛点： 1、系统不易理解：开发同学往往会发现原有系统设计和代码实现逻辑混乱，不知从何下手 2、代码不好修改：调整一个连锁的逻辑，会影响到原有一些很底层的功能，影响面很大 3、维护和部署不方便：改动一个连锁的功能，需要发布核心应用

整体而言就是在涉及到连锁解决方案的需求时，研发的生产力会比较低。

于是就在想，有没有办法通过一些优化和设计，来让连锁的开发同学： 1、更快速的理解一个业务，做出合理的技术设计 2、更舒服的编写代码 3、更安全的发布一个新功能

在探索和实践这件事情时，大致的思路是这样： 1、找一个具体的连锁场景，分析其业务逻辑：这里我找的典型场景是商品，考虑到大家对商品都比较了解； 2、分析下现在是怎么实现的？ 3、现在这样的实现方式，会有哪些问题？ 4、怎么去优化它？

三、连锁业务现状

3.1 商品业务场景

这里用一个多维表格，描述下一个简单的 B 端商品业务流程，包含：商品创建、上下架、查看和编辑。

横轴是业务场景，纵轴是组织类型，中间的内容，是这些业务场景在对应的组织类型上会有什么样的表现：注： 1、横向越权控制，是指总部只能操作总部下的门店，而不能操作归属于其他总部的门店 2、总部编辑商品，信息同步至门店时会有一定的同步规则，不是所有信息都会同步过去，这里不展开细讲，知道有这样一个逻辑即可 3、同样的，对于从总部上架过来的商品，门店只允许更新部分属性，这些都属于连锁经营场景下的特有逻辑

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。

基于上面的「业务场景-组织关系」的二维矩阵，我们发现可以把业务场景做进一步的抽象和拆分，分成： 单店能力 + 连锁能力

划分的标准很简单，如果一个能力是单店商家就需要有的，那就属于单店能力，如果是连锁商家（两个或两个以上门店的商家）才需要的能力，那就属于连锁能力。

我们来看看如果按照上面的划分标准，之前的场景可以抽象出哪些能力，这些能力属于单店能力还是连锁能力：

简单描述下： 1、总部下创建商品，其实就是在一个店铺下去创建商品，明显是单店能力； 2、总部把商品上架到门店，商品上架，本身属于单店能力，但是针对总部对门店的横向越权控制，这个属于连锁的范畴； 3、同样的，编辑商品、下架商品，这些也是单店能力，但是编辑总部商品后，信息怎么同步给门店，门店可以编辑哪些商品属性，这些则是连锁场景下才需要的能力，属于连锁的范畴。完成这样的结构化分析后，我们再把之前的场景进行一个拆分：

虽然只是给一团浆糊来一刀，变成两团浆糊，但是会发现这样的划分，能帮助我们更好的思考，并且基于这两团浆糊，做出更多的设计和优化。

4.2 部署方式

把商品能力拆解为连锁能力和单店能力后，在部署方式上也进行了对应的设计，来支持业务的快速发展和系统的稳定：商品的单店能力由 mei-goods 实现，连锁能力交给 mei-chain 负责。当然如果单店和连锁能力都需要再往细拆分，也可以拆分成更细的服务。

带来的好处是： 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 实践起来的难度，这时候我们对业务场景划分了边界，先聚焦在单门店的场景，再聚焦在连锁的场景，把他们分成两个独立的领域去解决，比如在这个例子里，我们把商品分成单店商品领域和连锁商品领域，他们合起来共同为有赞的商品领域提供解决方案。