分層架構演化：從單體的插件化演化所引起的思考
最近，在為 Coco 優化分層架構之時，我陷入了各種決策困難之中。所以我通過不斷地延遲決策，以摸清更適合現有系統的現狀。換個簡單來說，在危險邊緣徘徊，以期待能獲取最大的收益。
在設計新的架構時，我們總會憑借原先的經驗，并結合業務現狀的需求，并根據未來的需求做出我們的設計。即：
- 過去的經驗。
- 現在的需求。
- 未來的方向。
種種因素的影響之下，它注定了我們無法設計一個滿足所有歷史時期的系統。未來會變成現在，現在會變成過去。
Coco 架構設計：從過去到過去的未來
原先對于 Coca 的各種設計問題，以及 Golang 對于多平臺的支持問題等多方面的因素。迫使 Inherd 開源小組在 Coco 在初始階段，便考慮了為 Coco 設計插件系統。直到最近，我們實現了插件系統之后，發現了原來設計的分層架構已經不滿足現今的需求。
雖然，我已經知道新的分層架構應該如何設計，但是我并不想朝那個方向過去。我走走彎路，再看看是否存在一些更有意思的設計。
原始形態：單體架構
在設計初期，我在 Coco 中引入了類似于 Clean Architecture 的分層架構設計(不包含 Cargo 模塊)：
- app，對應于用例(usecases)。
- bin，對應于 controller。在 Rust 的構建系統中，bin 目錄的會被構建出可執行文件
- infrastructure，對應于 基礎設施，如調用 Git 的接口、訪問文件系統等。
- domain，即業務實體、領域模式，包含了系統的業務設計。
在 domain 目錄下，根據了我們的四大基本業務，進行了二次劃分 ：
- cloc
- git
- framework
- architecture
- ……
盡管，我一直在說我采用的是類似于 Clean Architecture 的分層架構。但是實際上，并沒有采用其中一些重要的設計，比如說通過依賴反轉來控制流向的問題。從個人的角度來看：
- 它帶來一定的架構復雜度，需要不斷地傳遞相關的架構知識，能否在開源項目中推廣，有待商榷。
- 后續可以通過重構來轉換。我并非非常資深的架構專家，所以以學習為出發點更方便。
作為一個單體應用，這個分層結構湊合著：
- 不算太復雜，還能讓開發人員知道哪的代碼往哪里放。
- 可以按需演化為 Clean Architecture。
- 模塊可以進一步按業務拆分。
故事的開始還是蠻美好的。
復用形態之模塊化
為了在多個不同的系統/應用之間(即 Coco 項目的代碼提供給其它應用)復用代碼 ，系統中產出一些獨立的模塊，如 psa、framework 等等。這也是一個非常常見的模塊化的場景。模塊化在不同的語言里都有一定的相似之處。
譬如：在使用方式上存在本地使用和遠程發布兩種模式。在本地使用時，無需關注語義化版本等一系列的事項，只需關注于代碼本身。一旦時機成熟，也就可以進化為可遠程發布的模塊。
從單體中出現模塊化的一種典型形式便是，在代碼庫中以與源碼同級的目錄呈現。如下：
- ├── framework
- ├── psa
- ├── src
- │ ├── app
- │ ├── bin
- │ ├── domain
- │ ├── infrastructure
- │ └── lib.rs
這里的 framework 和 psa 便是獨立的模塊，一旦其與其它模塊的依賴關系解耦開來，那么它就可以作為獨立的應用發布。
復制 over 復用
順便提一句，對于模塊化的代碼復用來說，如果代碼量較少，那么可以嘗試復制一份代碼，而不是復用做代碼。這樣一來，我們可以通過此來解耦依賴。
插件化的架構演變
同時，為了靈活地擴展系統的功能，我們設計了插件系統。(事實上，更多地從意圖上，我們只是為了減少包體積大小，這樣可以方便地從 GitHub 下載)
于是乎，我們創建了獨立的 plugins 目錄，并在其中創建了對應的模塊，如下的 coco_xxxx 即是插件。同時，我們使用了 plugin_manager 來作為插件的管理器(事實上，后面證明了，這個 manager 不應該獨立作為一個模塊存在)：
- ├── framework
- ├── plugin_manager
- ├── plugins
- │ ├── coco_container
- │ ├── coco_pipeline
- │ ├── coco_struct
- │ └── coco_swagger
- ├── psa
- ├── src
- │ ├── app
- │ ├── bin
- │ ├── domain
- │ ├── infrastructure
- │ └── lib.rs
從設計和演進的角度來看，問題并不多，也可以使用。
演進：未來的未來
好了，由于經驗上的不足，我們就面臨了之前沒考慮到的問題。
提取核心模型
從設計思路上來看，我們本應該在原先的架構模型中，提供一個 core 模塊。而在這個 core 模塊里呢，則用于提供一些核心的代碼給插件和應用。
所以，很快地我們就創建了一個 core_model 出來了。我的本義也就只是提供一個核心模型。我不想像一些插件化項目中，在 core 中提供大量非核心的代碼。
只是呢，隨著第一個模型復用需求的出現，很快地就有了第二部分、第三部分。
再次抉擇：基礎設施層的改造
而插件之間除了模型的復用，還會有基礎設施的復用。而這些代碼，我又不想放到 core 里，所以就又需要抽取中一個 infra 的模塊，用來共享基礎設施的代碼。那么問題來了，我們應該如何選擇?
- 將原有的 infrastructure 提取到主目錄下，作為單獨的模塊存在。
- 雙層infrastructure，即只提取共用的代碼，到主目錄下，作為獨立的模塊。
從架構設計的思想來看，我是支持雙層基礎設施的存在。過多的無意識地復制這些公共代碼，會導致這個包大小的進一步膨脹。一個典型的例子，就是我們在一個被稱為 common 包的 jar 包里，看到一個 common 子包下，還有 common 目錄的存在，即 xxx-common.common.common。
小結：架構的持續演化
故事就到這里了。哪怕一個再小的項目，它的架構模式也會隨著系統的開發，不斷地演化。如果不加以控制，那么系統可能會推動控制。而演進本身呢，也不會是一帆風順的。
不過，我在思考一個新的東西，關于『分層架構適應度函數』。
Yiki：分層架構適應度函數
無論是在 Coco 還是在 Coca 里，我們都在嘗試對系統的分層進行一個評級。而這個評級的其中一個依據是通過依賴關系，來確認各個模塊之間的引用關系，從而判斷系統的分層架構是否是符合需求的。
通過解析模塊之間的引用關系，可以幫效地幫助我們厘清系統模塊之間的合理度。
本文轉載自微信公眾號「phodal」，可以通過以下二維碼關注。轉載本文請聯系phodal公眾號。
