关于通用框架的一些想法

前言

前几天跟朋友谈起框架的事情，回顾了一下当前框架的发展，尤其是spring boot，已经把程序员的开发简化到了最初的一个 class 的形式了。这个也是我为什么喜欢领域驱动设计（ddd）的原因，真正回归了本源。回头看历史上的各种框架，从struts开始，到tapestry、wicket、springmvc，最后到spring boot，就是逐渐破坏面向对象（oo）的封装性，再慢慢回归到面向对象的历程。

通用框架的一些概念

我画了一个图，是应用程序的结构，貌似是spring cloud/boot的结构，实际上并不仅仅如此。

我们从底向上分析这个图：

• 底层是操作系统，目前流行docker，以及基于docker的各种派生工具，比如kubernates、rancher等。但是微创新不能改变本质，也就是docker带来了和纯os之上部署完全不同的一种方式。但是依然属于“部署”的领域。在这个领域中，我们要思考的是拓扑结构、设备内存大小、磁盘空间、网络参数、文件句柄等。
• 操作系统之上，就是应用系统的各种部件。现在的应用系统，都是异构的，如数据库用mysql、oracle，缓存redis，传输kafka、mq等等。这些异构的外部第三方程序需要和自己开发的应用进行集成。这是“系统集成”的领域。在这个领域中，我们要思考的是地址、端口、应用系统的配置参数等。
• 在自己开发的应用程序结构中，如果用java开发，则要基于java运行时之上，结合外部的各种库，然后才能在其上开发自己的业务逻辑。这些业务逻辑代码通过编译打包功能，和外部库文件一起构成应用程序。这是“应用集成”的领域。在这个领域中，我们要在代码级别思考api、性能、参数、返回值、调用方式等。
• 最上层才是自己真正开发的应用逻辑部分。现在一切都回归到“对象”，程序员们只需要把业务逻辑写在class里就可以。但是写出这些代码之前，我们需要进行设计，思考各个class之间的关系，思考界面和后台逻辑的调用方式，思考界面的布局、交互等。这些才是开发真正要关注和要做的事情。

把上图换一种画法，可以更加容易看懂。一层层象蛋壳一样的结构表示不同模块所处的依赖层面。现代软件框架已经发展成了一个庞大的体系，我们需要人工编程的部分，就像鸡蛋的蛋黄一样，核心但是只有一点点。

那么，我们刚才已经说了：

1. 基于现代框架的编程，已经回归且简单到只需要写一个class的地步了
2. 在手工编写内容之外，都是集成工作

通用架构也不过是如此。

关于通用框架的一些设想

目前框架方面的顶尖水平依然在java界，以spring boot为代表。现在流行的spring cloud的核心依然是spring boot。记得2015年的时候，我用dubbo给客户搭建了一个框架，后来在研究spring cloud的时候，发现两个的框架的思路基本一致，编程方法类似。那么，从开发者的角度，能否屏蔽这种差异？

一旦屏蔽了框架实现的差异之后，开发者只需要用纯oo结构去实现自己的业务，框架根据annotation自动决定加载和运行。也就是说，我们可以把“框架”归类到运行时（runtime）部分，而不再需要把框架代码也打包到系统里。框架和代码之间的解耦，可以让应用程序的适应性更广：同一套代码，套用不同的框架，就具备了不同的特性，如高可靠、高吞吐量、离线处理等等。

看起来很美！