写在前面：在研究一个新东西的时候，我习惯于拿手头的项目去做类比，所以即使这些原则更多的是在描述面向对象，我在理解的时候也是在往嵌入式C实时系统去靠的。
先列上三个原则：
1. REP复用/发布等同原则：软件复用的最小粒度应等同于其发布的最小粒度。
2. CCP共同闭包原则：我们应该将那些会同时修改，并且为相同目的而修改的类放到同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的那些类放到不同的组件中。
3. CRP共同复用原则：不要强迫一个组件的用户依赖他们不需要的东西。
作为一个架构菜鸟，这里面有很多概念是模糊的。
首先，什么是复用。百度百科这么描述：“将已有的软件成分用于构造新的软件系统”，通俗讲，我觉得是这个迭代发布的成分功能，未来仍然在这个成分的基础上修改之后发布新的功能。
那么REP原则在主张什么。从代码角度，完全的REP原则会导致软件变大。比如特性跨组件是很常见的，按照REP原则，这些跨组件的功能应该属于一个组件。我觉得REP原则在组件设计中的作用非常虚，简单来说就是功能内聚。换个角度看REP，他提出了一系列非组件设计的要求：能容易地添加新的功能扩展，组件内的模块遵循统一的发布版本。
REP原则我觉得放在软件项目管理里非常合适。DDD强调划分特性团队，特性终结在团队，粗暴的特性团队划分又会导致架构守护困难，此时通过划分领域的方式将交付节奏或波及频率相同的组件划分到同一个领域能解决架构守护的问题。
共同闭包原则是组件级的单一职责原则。我一直觉得单一职责原则是水很深的原则。脱离业务，你很难说清什么叫单一职责。单一职责函数的命名实际上定义了文件或函数之间的统一概念和层次结构。变更频率相同的块放在同一个组件，变更频率相同从侧面描述了“相同目的”，这是REP更进一步的描述。CCP原则和开闭原则的关联有点略显牵强，其实还是在说统一变更频率。
共同复用原则建议将经常共同复用的类和模块放在同一个组件中。“当我们决定要依赖某个组件时，最好是实际需要依赖该组件中的每个类”，这条建议可以说非常具体了，它实际告诉我们哪些功能块不能被放在一起。
三个原则关系见下图:
三个圆圈把三个原则的本质目的讲得很清楚。不关注CCP会导致组件划分太多太细，即使简单功能也会波及很多组件；不关注CRP会导致大组件，很多小功能频繁发布。文中说，随着项目逐渐成熟，项目重心会左移，CCP移向CRP好理解：为了追求开发速度，组件功能小而单一，大组件维护方便，随着功能越来越多，就会进行组件拆分。向REP移动不是很好理解，主要是这里的复用性：怎样的组件划分能对新增需求更加亲和。待我再找找资料再来回答吧。
