一文一点 | 给你一份实现业务复用的指南

这是【一文一点】的第11篇学习文章，不拘泥于篇幅字数，用一篇文章说清一个知识点。

无论是微服务、组件化、乃至我们说的中台，根本都是在解决一个问题：效率，将已有或未有的业务能力和技术能力快速的匹配到前端业务的需求。

 

为什么还提到未有的呢，那是因为你有了基础，开发未有的业务功能也会很迅速。

 

软件工程设计中提高效率的基本核心思想就是复用，复用就是基于已有的系统功能，快速去实现前端业务场景需求。

 

甚至，良好的复用可以做到一生二，二生三，三生万物，顺便符合了中国人的哲学观，这就像七巧板一样任意拼装，形成一个新的形态的系统。

 

1、

在昨天的文章中，我们讲了复用的分类，可以分为技术复用和业务复用，技术复用相对好理解，我们主要是来谈业务复用。

 

业务复用又可以分为业务实体复用、业务流程复用、业务产品复用，如下图所示。

 

             

 

业务实体复用，比如京东商城的订单服务、商品服务等，可以给京东商城使用，也可以给京喜使用，这样无论上层业务是谁，这些基础服务都可以被快速提供出来。

 

业务流程复用，比如京东商城的入住业务流程，自身POP的商家入驻流程可以支持，同样也可以支持京喜商家的入住，因为我们已经抽出去相同的节点，包括主体认证、联系人、账户信息等等。

 

业务产品复用，比如京东商城的POP业务可以给国内使用，也可以给泰国、印尼等海外的站点使用，这就是产品复用，这是最高等级的复用。可以类似我们说的SAAS系统，真正做到软件即服务。

 

2、

在文章的开始，我们提到复用是基于已有的系统功能，来提高效率，那么我们的系统功能或者局部功能必须具备可复用的能力才行。

 

如何做呢。

 

（1）、划分边界

对于整洁架构中的业务实体这个核心圆，它的边界划分尤其要清晰，而且决不能含糊，这点异常的重要。

 

举个例子，订单服务在京东商城里面肯定是一个核心服务，如果其它业务调用端在查询订单信息的时候，也同时想获取商品信息，作为调用端是不是很希望订单服务可以把详细的商品信息一起返回给他呢。

 

但订单服务不能这样做，我们之前在讲整洁架构的时候，尤其强调了整洁架构的核心思想是不要主动依赖其它外部服务，包括其它核心服务。

 

实际上这里的商品服务也是一个业务领域内的核心服务，既然订单服务不能依赖商品服务，那用户端又想同时获取订单和商品的信息，应该如何做呢，方法就是组合。

 

此时应该要有一层来干这件事，由它来将订单服务和商品服务所暴露出去的信息进行封装，以便提供给用户调用端来使用，如果将来这个聚合服务被复用的频率高，那这就是一个共享服务。如下图所示。

 

             

 

这一层如果对应到DDD架构中，就是应用层，订单服务和商品服务，最终对外提供能力的形式都是以API的方式，那么实际上组合这两种API，就有点组合编排的味道了。

 

一个严格的DDD四层架构图，如下所示，我们上面说的订单服务和商品服务都在领域层，应用层来负责组合它们。

 

             

 

 

（2）、定义接口

为什么是定义接口？我们来思考下上面提到的，从业务实体复用到业务线复用再到业务产品复用，然后再思考下划分边界这块的内容，我们凭什么能让自己的核心基础业务可以被复用出去呢？

 

这其中的过程难道不是经历了模块化，我们把自身领域内的服务，比如订单服务，利用单一职责原则，对订单业务领域内的订单核心服务进行剥离，将与之无关的牵连，转移到其他系统中去么。

 

然后，我们针对剥离出来的核心功能，形成标准，进一步规范化处理，以便让将来的所有调用方，在使用的时候都能够统一的属性。

 

最后一步应该做什么呢，是不是就要提供能力出去了，我们不能嘴上说复用，结果却没有复用的能力。

 

那么，你提供能力的形式载体是什么呢，最终还不是以接口的形式么。

 

之所以复用能力能够提供出去，是经历了这么几个阶段的，那就是模块化-标准化-接口化。

 

你可能会觉得上面说的过于理论，如果是一个新的应用，我按照模块化-标准化-接口化的方法可以很快落实，但是如果是一个存量的应用应该如何实施呢。

 

这是个好问题。

 

首先呢，大家要认清一点，那就是现在我们面对的是一个业务复用的问题或者叫做领域吧，它本身就包含了功能和数据，这里面，我个人认为，对于存量的应用，难点就在数据上。

 

也就是我们要首先要对数据库“下手”。

 

如果你再遇上设计不那么合理的存量应用，比如数据之间关系、与其它模块之间的关系，从而导致，你下手的时候，它是一个那么棘手的表。

 

还是拿订单来举例吧，首先你要找出跟订单业务不太相关的表，然后将它们剥离出去，继而圈出跟订单业务属性强关联的数据表，其实这一个过程也是划分边界的过程。

 

当你确定好订单有哪些相关的表之后，就要想办法收集相关的SQL语句了，因为这个涉及到你后面真实的代码逻辑的改造，有些SQL语句可以继续保留在当前这个模块，有的你就有可能会想办法去调用其它的服务来请求数据。

 

因为之前你已经把表拆清楚了，所以如果遇到关联查询的SQL语句，肯定会涉及到服务化的过程，比如有一张促销表已经确定要剥离出去，但是呢，当时又有管理订单和促销的查询，这个时候也就只能各自确定好边界，然后以服务的形式提供出去了。

 

记住，这样的工作并不是一件容易的事情，它的困难往往不是来自技术本身，而是来自组织，你想啊，拆出去的那部分谁来承接，以及这中间的沟通成本，因此我们有时候戏称，这是一项技术Leader工程，往往需要你的老板参与其中的。

 

             

图自网络

 

3、

业务实体复用是其它复用的基础，业务实体复用的过程经历了模块化-标准化-接口化的阶段，这里面模块化又是标准化和接口化的基础。

 

能力的供给载体形式最终肯定是以接口的形式出去的，所以我们最后提供的能力都是具有良好设计风格的接口。

 

本文完。