目录
前言
我们日常的开发中，经常会写各种各样的类，但是哪些类应该组成一个组件，这个问题我们时常会有疑问。按照正常的逻辑，如何聚合应该按照最佳的软件工程经验来做。但是实际的做法，大部分都是拍脑门决定的，都是想当然。
在长时间的软件工程实践中，人们总结出了三大基本原则。
一、复用/发布原则
这句话是说软件组件中的类和模块必须是彼此紧密相关的，一个组件不能由一组毫无关联的类和模块组成，他们应该有一个共同的主题或者大方向。比如说做饭，需要有买菜，做菜，端菜这几个大的过程，我们可以吧买菜相关的类放在一起，组成一个组件。
一个组件中的类与模块应该是可以同时发布的，意思是买菜方法改进了，变成了买菜2.0，升级买菜过程的时候不应该受到做菜方法的影响。能独立的进行组件升级。
二、共同闭包原则
我们应该将那些会同时修改，并且为相同目的而修改的类放到同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的哪些类放到不同组件内。
这个原则告诉我们，对于大部分软件来说，可维护性的重要性要远远高于可复用性。如果某程序中的代码必须进行某些变更，那么这些变更最好都体现在一个组件内，而不是多个组件中。如果是这些变更在一个组件中，我们就只需要重新部署该组件，而其他组件不需要被重新验证、重新部署。这样就有效降低了因为软件发布，验证，部署带来的工作压力。
在这个原则基础上，还可以进一步延伸，可以把某一类变更都聚合在一起，意思是比之前的相同目的修改更高一级聚合，最大限度减少因该类变更导致的修改。
三、共同复用原则
共同复用原则是另外一个帮助我们决策类和模块归属于哪一个组件的原则。该原则建议我们将经常共同复用的类和模块放在同一个组件内。
通常情况下，类很少会被单独复用。更常见的情况是多个类同时作为某个可复用的抽象定义被共同复用。共同复用原则指导我们将这些类放在同一个组件中，而在这样的组件中，我们应该遇见到会存在着许多相互依赖的类。
共同复用的原则，不仅是告诉我们应该将哪些类放在一起，更重要的是告诉我们应该将哪些类分开。因为当一个组件引用了另一个组件时，就等于增加了一条依赖关系。虽然这个引用关系仅涉及被引用组件中的一个雷，但他所带来的依赖关系丝毫没有减弱。也就是说引用组件已然依赖于被引用的组件。
举个例子，我们引用了一个jar包，这个jar包引用了一个很大的另外一个jar包，但是其实只用了其中一个很小的util类，这种情况，就会导致，就会给我们的项目带来很大的维护风险，依赖的越多，越有可能会冲突。发布的包就会越大，相应的运行和存储空间就成几何倍数增长。
组件聚合张立图
优秀的架构师应该能在上述的三角张丽区域中定位一个最合适目前开发团队状态额位置，同时也会根据时间不停调整。项目早期，可维护性比复用性更重要，因为这一阶段，研发速度比复用性更重要
一个组件在组件结构设计上中心是根据项目的开发时间和成熟度不断变动的，我们对组件结构的安排主要与项目开发的进度和它被使用的方式有关，与项目本身的关系其实很小。
总结
这三个原则为我们描述了一个更为复杂的决策过程。在决定将哪些类归为一个组件时，必须要考虑到研发性和复用性之间的矛盾，并根据应用程序的需要来平衡这两个矛盾，这是一件很不容易的事。而且这种平衡本身也在不断变化。也就是说当下合适的分割方式明年可能就不适用了。所以，组件的构成安排应该随着项目重心的不同，以及研发性域复用性的不同而不断演化。
