思想来源
在做前端应用的过程中，我经常发现组件之间、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的架构只是对流程的抽象和分层。聚类分层就是针对每一个流程分层内部的扁平的资源，通过聚类特征，使之层次化，结构更清晰。
此外，聚类分层的思想并不只是在前端应用中可用，虽然我只是举了一些前端应用场景，但是这种思想是通用的。
