思想來源

在做前端應用的過程中，我經常發現元件之間、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的架構只是對流程的抽象和分層。聚類分層就是針對每一個流程分層內部的扁平的資源，通過聚類特徵，使之層次化，結構更清晰。

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