前端架构思想：聚类分层

思想来源

在作前端应用的过程当中，我常常发现组件之间、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的架构只是对流程的抽象和分层。聚类分层就是针对每个流程分层内部的扁平的资源，经过聚类特征，使之层次化，结构更清晰。

此外，聚类分层的思想并不仅是在前端应用中可用，虽然我只是举了一些前端应用场景，可是这种思想是通用的。