前端架構思想：聚類分層

思想來源

在作前端應用的過程當中，我常常發現組件之間、store的module之間關係錯綜複雜，扁平的結構並不能表示其關係，隨着組件和module的增長，代碼愈來愈混亂，維護成本也越來也高。我對這個問題的解決進行了一系列思考，實踐的過程當中總結出了聚類分層思想。

聚類分層思想

什麼是聚類分層思想

前端如今主流的組件-flux架構中（以vue舉例），有組件層、store層，組件層能夠細分爲模板和vm，store層又能夠拆分紅各個模塊。

隨着功能和業務邏輯的逐漸增多，每層和每一個模塊都有不少相同的東西，好比組件層會有不少組件，store層會有不少module，一個組件的vm也會有不少的methods。當這些東西的數量逐漸增多時，他們之間的關係會愈來愈模糊，因此，咱們會進行一下分類，好比把組件分爲頁面組件和基礎組件，這是經常使用的分類。把有必定共同特徵的某種資源（組件、module、methods等）進行聚類，使之多出一個層次，這樣會使得結構更加清晰，把扁平的結構變成更加清晰的多層結構，這就是聚類分層思想。

扁平化和層次化

就像公司發展同樣，創業公司架構通常都比較的扁平化，基礎的部門，每一個部門分個一兩層，隨着公司業務的發展，架構也會從扁平走向多層，好比每一個部門先按照業務分紅幾個事業部，而後每一個事業部再分爲幾層。這些都是公司大了之後保證結構和職責的清晰必經之路。

應用也是同樣的，隨着功能和業務邏輯的增多，在以前代碼的基礎上進行開發須要瞭解的東西也愈來愈多，依然用扁平的結構會致使學習和維護的成本增長，同時由於結構和職責的不清晰也會容易把代碼放錯位置，功能愈來愈多的過程，也就伴隨着代碼愈來愈混亂。

聚類分層思想的應用

扁平的結構變成多層的結構，可使用聚類分層思想，按照某一種特徵來分類。好比 組件的聚類特徵能夠是組件的複用程度，分爲基礎的可複用的組件和組合基礎組件的容器組件

也能夠按照組件是否渲染ui分爲2類，而後負責渲染ui的組件根據負責展現仍是負責交互分爲交互組件和展現組件，不負責渲染ui的能夠根據是負責接入數據的仍是其餘功能可分爲接入組件和功能組件。功能組件好比 router-view，transition等。

vm層的methods的聚類特徵能夠是處理的內容，分爲處理交互事件的event handler，處理通用邏輯的util method，也能夠是處理中間過程的 middle method。

store層的module的聚類特徵能夠是封裝的數據所對應的目標，分爲 對應頁面組件的，對應基礎組件的，對應實體的，和一些通用數據的。

上面是一些常見的和我想出的聚類特徵和根據聚類特徵的分類結果，固然，聚類的特徵並不惟一，好比也能夠根據業務特徵來聚類，具體的聚類特徵根據具體狀況來肯定。

流程分層與聚類分層

代碼運行是有必定的流程的，好比客戶端的應用，主要的流程就是取服務端的數據處理後顯示在界面上，把用戶在界面輸入的數據處理後發送到服務端，同時本地可能也會維護一份副本。

應用會使用一種架構模式來組織這個流程，好比mvc或者組件-flux等，大致上把數據、邏輯、視圖進行了分類，不一樣的代碼和資源放入不一樣的層次。每條業務流程須要在每一層創建對應的模塊。

可是隨着功能和業務流程的逐漸複雜，也就是每層的模塊逐漸增多，每層模塊與模塊之間的關係也會愈來愈錯綜複雜，可是並無一種明確的思想或原來來明確指出這個階段該怎麼辦。

聚類分層就是解決隨着業務流程增多而增多的模塊經過扁平的結構不能表現出其之間的複雜關係的問題的思想。使用聚類的思想，按照某一種特徵，對按流程分層的每一層的模塊，再按照某一種特徵進行更細的分層，使得模塊之間的關係變得更加清晰。不一樣業務模塊之間的關係不一樣，聚類基於的特徵點也不一樣。

總結

聚類分層思想是解決扁平化的結構不能清晰表示資源之間的關係的問題，經過按照必定的特徵來聚類，使之層次化，使資源間的關係更清晰也更易維護的思想。

按照不一樣的應用場景，聚類特徵也不盡相同，但有一些通用的聚類方式，好比容器組件、展現組件等。

聚類分層是對流程分層的補充，mvc或者組件-flux的架構只是對流程的抽象和分層。聚類分層就是針對每個流程分層內部的扁平的資源，經過聚類特徵，使之層次化，結構更清晰。

此外，聚類分層的思想並不僅是在前端應用中可用，雖然我只是舉了一些前端應用場景，可是這種思想是通用的。