组件耦合

通读完《架构整洁之道》全书，回过头再来写总结和感想，真不是一件容易的事。之前在《禅与摩托车维修艺术再探》里我说，写这类文字是一个合上书又翻开书的过程，合上书回想主要收获，翻开书做有重点的二次阅读。这篇就是翻开书。

组件耦合

这一章节除了已经广泛应用的每日构建外，主要讲了三个原则：无依赖环原则、稳定依赖原则、稳定抽象原则。

到这里我想到这些原则、规则、law与程序员之间的关系。作为一名程序员，这些原则应该要内化掉，了解原则之后至少要指导一次编码实践，在实际需求中这些原则应该共同组成程序员的良质（《禅与摩托车维修艺术》），指导程序员追求更加有序、节省人力的设计方法。作为一名TL、SE或者架构师，我逐渐意识到，这些原则是需要有意识地收集、整理、举证、实践的，因为这类角色经常需要去给别人讲东西，经常需要推动一些改革，工作重点中有一大部分都是与人打交道，已经不止是应用，更多地变成了一本行走的书，我想架构师团队应该至少把不同方面不同角度的原则整理出来，将零碎的知识点归纳出来，作为指导设计和健康度评估的checklist。

组件依赖关系图中不应该出现环。组件间难道不是通过接口通信的吗？怎么会出现环呢？我意识到我认为的“组件”和这里说的“组件”出现了不一致。《组件》一章说“组件是软件的部署单元”，可以独立部署，也可以做成插件进行动态加载。我想《组件耦合》一章里说的组件，应该是插件，只有插件才会出现互相依赖的情况，可独立部署和发布的组件一般都是依赖于接口的。自然也就不会出现依赖环。依赖关系图可以通过structure 101或者understand这类软件自动获取，用以评估当前组件间依赖关系是否符合预期。无依赖环原则不只适用于组件间，也适用于模块间，即domain层的各个文件夹之间，反思一下，模块间的依赖关系确实是很容易出现环的，模块间的依赖关系很难守护，这往往是业务模型或者算法决定的，这一阶段的设计一般很少考虑依赖关系，在业务专家看来，就像坐在办公桌前面对一桌子的零件，每一个具体问题都可以拿来用来解决问题，机械专家组装机械的时候零件A上需要零件B，零件B上又需要与零件A同一厂家的零件，将来一旦A厂家更换，B的处境就很尴尬，整个系统面临失败的风险。这是一个很现实的问题，这要求业务专家也必须了解“实际”，不能制造空中楼阁，最近新看一本书《系统架构》，就是在说不单单程序需要架构师，所有人造系统都需要架构师。

与三个原则同级标题的，有一个“自上而下的设计”，书中认为“组件结构是不可能自上而下被设计出来的，它必须随着软件系统的变化而变化和扩张”，这与《UNIX编程艺术》的观点是不一致的。关于自上而下还是自下而上，是分场景的，软件是要尽量自上而下的，但一个项目演进过程中总会遇到新的变化方向和聚合实体，这就需要自下而上。熟悉系统的第二次开发是自上而下，新系统的开发是自下而上。

依赖关系必须要指向更稳定的方向。前两天交流的时候我举了个例子，模块A有流量统计的功能，模块B也想做流量统计，那B能不能直接拿A功能用呢？不能，要把流量统计功能提取出来，A和B共同依赖于流量统计。模块的稳定性，书中给了详细的量化稳定性的方法可作参考，一个组件的稳定程度取决于它的修改频率、修改的方式、获取实例的多少、抽象化程度，上面举的就是抽象新模块的例子，修改频率高的模块不稳定比如A和B模块，如果修改的方式总是按系统原始设计的变化方向进行修改也可以认为是稳定的，获取的实例越多、输出越多表明模块与外部的联系越多外部修改很容易引发修改也就越不稳定。

一个组件的抽象化程度应该与其稳定性保持一致。这个原则与上面稳定依赖原则有点像，在依赖于抽象的基础上又做了进一步的要求。稳定组件要高度抽象，否则就会难以修改。比如组件内的主流程，就要足够抽象，主流程太关注细节会导致难于扩展，具体的实现要放到实现层。