无论组件化也好,中台也好,都是在解决效率的问题,那么这背后的基础都是复用,在讲复用之前呢,我们先来了解架构,因为良好的架构是复用的基础保障。
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,这些都是指的技术复用。
那么什么是业务复用呢。
这个还可以继续细分,有业务实体的复用,业务线的复用,业务产品的复用,它们的层级也是逐渐升高的,业务产品复用的等级最高。
这其中业务实体的复用是其它两种复用的基础,这也就是我们在整洁架构中重点阐述的业务实体层,那个核心圆,所以做好了业务实体的复用是业务复用的关键。
本文完。