模块化

模块化是什么，C项目里的模块化是什么意思。

先说模块和组件的关系，组件好理解，组件是独立部署和发布的单元，相同组件内的代码应该有相同的变化和发布频率。模块是组件内功能内聚的单元，这句话很贴切，但，这是一句废话，说得太大，不具体就没有任何意义。

我们看下面这个图，这是组件内frame与模块的依赖与调用关系的现状图。粗线表示frame流程，红线表示模块在frame上的调用点，细黑线表示模块之间的调用与依赖。

从图中可以看到，frame的调用点间存在模块交叉，模块之间存在网状依赖。这是两张网，frame与模块的关系，模块与模块之间的关系，都是网状的。

长期下去，大量frame的流程陷在模块的泥潭里，看代码的人找不到头绪；新的需求分析不清楚模块间的波及，bug丛生。

所以我们需要厘清并规范化frame与模块，模块与模块之间的关系，这个改造过程我们称之为模块化。

模块化是一项巨大、困难，又缺乏资料指导的工作，一切结果都来自架构师自身的经验和聪明才智。

模块化的第一步，是要说清楚什么是模块。

我们加入一个视角，feature。代码可以看做是由frame与feature交叠而成的。feature是不是一个模块？frame按照流程边界劈两刀，劈开的部分是不是模块？

到目前为止，还没有答案。下面谈一下我的想法。

我认为，模块必须有自己私有的数据。假如划分出的模块没有自己私有的数据，那就是一个纯流程的操作，这样的模块天然不具有单一职责。举个例子，组件都有参数配置层，所谓参数配置层，我认为就是一种假的模块，这个层的代码变化频率不一致，没有一个人或者团队能脱离模块去维护这个参数配置层。

所以把frame劈开的做法，唯一的作用是暂时让新员工看代码的时候容易一些。长期下去，由于这样的“模块”所有人都在改，逐渐会边界模糊，而模块化的初衷“要坏就坏在模块内”也无法达到。

模块也有共享给其他模块的数据，通过特有的接口层来提供这些数据的访问。模块会有一些“工具函数”，其他模块可以调用这些函数获取特定的计算结果，之所以加引号，是因为这种函数获取的结果是基于模块内部的状态的。

我认为解决上述网状关系的手段不是模块化，而是分层。定义清楚应用层、领域层、基础层，仔细设计领域层模块内的层次关系，剥离公共部分形成新的层。

我认为frame与模块的网状关系是没有太大关系的。模块为frame提供服务，多几处调用点是一件很自然的事。而清晰地区分出来frame和模块是一个很有意义的事，我们可以用frame把模块穿起来，并做checker检查frame只允许加函数不允许加实现。

模块化还是没有说清，怎样组织组件内的流程、特性、公共数据、私有数据是一件复杂的事情，任何一个决策都可能会带来一定的代价。这个主题还会有后文，过一段时间有新的思考再写第二篇。