關於通用框架的一些想法

前言

前幾天跟朋友談起框架的事情，回顧了一下當前框架的發展，尤爲是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）部分，而再也不須要把框架代碼也打包到系統裏。框架和代碼之間的解耦，可讓應用程序的適應性更廣：同一套代碼，套用不一樣的框架，就具有了不一樣的特性，如高可靠、高吞吐量、離線處理等等。

看起來很美！