一文一点 | 什么才是复用的最高等级

无论组件化也好，中台也好，都是在解决效率的问题，那么这背后的基础都是复用，在讲复用之前呢，我们先来了解架构，因为良好的架构是复用的基础保障。

1、

在昨天的文章中，我们有说到当今软件设计的世界流行着四大架构DCI架构、DDD架构、六边形架构和整洁架构，那什么是整洁架构。

不好描述对吧，那就直接上图，这张图是Robert C. Martin博客上面的一张整洁架构图。

按照《架构整洁之道》这本书中的介绍，这张图描述的核心思想就是：向内依赖。

怎么讲，就是外层圆依赖内层圆。

整洁架构也是分层的架构，只不过这里的层，不再是我们之前认为的上中下，这样的层，而是变成了内外层。

这里要注意的是，以前的上中下的层次结构中，我们说最上面的就是高层，最下面的是低层，都是由高层依赖低层，比如Controller依赖Service，Service依赖Dao。

到了整洁架构这里面，越靠近中心的层，越高，也就是内层圆是【高层】，外层圆变成了低层，而且依赖关系只能是外层圆依赖内层圆，也就是变成了低层依赖高层，就是上面我们说的向内依赖，记住这是整洁架构的核心思想。

2、

在只能外层依赖内层的机制下，或者说是规则，那么既然是规则，就是我们要遵守，但是，如果业务上就有，内层依赖外层的情况怎么办呢。

其实，如果你仔细看，并认真思考的话，你会发现，这张整洁架构图的右下角就描述了这样的场景：从控制器开始，穿过用例，最后执行展示层的代码。

用例需要”依赖“展示层的代码，用例需求把自己的表达通过展示层展示出来。

可是，我们不能破坏整洁架构的依赖原则，这种情况下就需要我们采用依赖倒置的方式了。

依赖倒置是一个很巧妙的方式，直接点说就是依赖接口，依赖抽象，或者面向接口编程，或者面向抽象编程，这些都是依赖倒置的表现形式。

这样用例没有直接依赖展示层的代码，而是依赖了一个“用例输出端”这样的接口。

3、

我们这里在来聊聊这个依赖倒置，刚刚我们只是说了依赖接口，依赖抽象等等，只是说了依赖，但是【倒置】呢，哪里有倒置的味道呢。

搞点小插曲，我还真上网搜了下，给大家截张图。

看到没有，把这位同学捉急成啥样了，把《设计模式之禅》搬出来了，也没有找到倒置在哪里，更有同学去查了【倒】的汉语词典。

依赖倒置，不仅仅就是我们说完面向接口编程或者面向抽象编程完事，更深刻的是一种对事物思考方式的转换。

按照正常的思考方式，我写一个A类需要依赖B类，那么首先我要先定义出这个B类，比如定义出B类的方法等，然后我再写A类，这时的顺序是B->A。

此时，如果这个时候我写一个接口G，在G中定义好了方法，让A类依赖接口G，最后我再让B类去实现接口G，这时的顺序就是A->B，与原来的思考顺序方式倒置了。

所以，依赖倒置设计原则中的倒置，本质是思考顺序的倒置。

4、

好了，再回到我们的主题上面来，我们现在瞄准上面那个图的靶心，也就是最里面的那个圆圈，业务实体。

上面我们说了越往里，越是高层，越是核心，也就是整洁架构所述的“外层圆代表的是机制，内层圆代表的是策略。”

那么，当然地，处在靶心位置的业务实体，就是我们整个系统的关键业务逻辑，我们可以看一下《架构整洁之道》中对业务实体的描述。

业务实体这一层中封装的是整个系统的关键业务逻辑，一个实体能是一个带有方法的对象，或者是一系列数据结构和函数，只要这个实体能够被不同的应用程序使用即可。

如果你没有编写企业软件，只是编写简单的应用程序，这些实体就是应用的业务对象，它们封装着最普通的高级别业务规则，你不能希望这些实体对象被一个页面的分页导航功能改变，也不能被安全机制改变，操作实现层面的任何改变不能影响实体层，只有业务需求改变了才可以改变实体。

足见，业务实体是多么重要，关键还有一点，业务实体不会依赖外层圆的任何内容，这就给了我们做业务复用最强有力的支撑。

5、

终于要到了我们说到复用了。

复用可以分为技术复用和业务复用。

技术复用比较好理解，比如，小到你写了一段计算日期的代码，封装到了一个jar，供别人使用，大到比如公司的所有业务线都在使用中间件研发团队的MQ，这些都是指的技术复用。

那么什么是业务复用呢。

这个还可以继续细分，有业务实体的复用，业务线的复用，业务产品的复用，它们的层级也是逐渐升高的，业务产品复用的等级最高。

这其中业务实体的复用是其它两种复用的基础，这也就是我们在整洁架构中重点阐述的业务实体层，那个核心圆，所以做好了业务实体的复用是业务复用的关键。

本文完。