软件模块和领域概念

技术上我们经常强调模块化、组件化，但是能真正实现软件模块化，需要通过对业务领域有一定程度的理解才能达到。

我们可能有专业培训组件和模块技术的课程（OSGi等），但这类课程并不会告诉我们所在的领域上具体情况应该如何划分模块，大概辨别和划分模块的能力是理所当然。但事实上并非如此。

用一个例子说明：假如一个网站需要添加一个广告功能。大概有以下可能性：

• 如果该网站本来是没有模块化的，直接就往代码里做修改。而后果会是代码越来越庞大
• 如果该网站已经划分了不同的模块，我们会看看新的功能是否属于哪个曾经定义过的模块，然后新的代码会在这个模块里添加
• 如果新功能不属于任何曾经定义过的模块，我们会建立一个新的模块。

最后两点的关键在［属于］如何界定。

新的广告功能［属于］内容管理（CMS）的一部分吗？毕竟广告也会有内容的特性（有文字，图片，超链接等等）。

广告功能也可以自成一个模块，因为广告的点击率直接影响网站收益，跟网站内容的点击性质不一样，处理的结果也可能不一样。

另外有可能广告功能是市场部管辖的范围，广告的效果经过分析后可能会到业务部和财务部做核算。从业务流我们也可以认为这个广告功能属于市场部的一个系统功能。

在Eric Evans的Domain Driven Design提倡领域设计的重要性，当中Bounded Context提到模型边界问题。而Sam Newman在Building Microservices书中也提到微服务最好也依据Bounded Context来划分。

通常我会依据以下关系来做模块划分：

• 领域对象的拥有者和使用者
• 根据企业的自然边界（部门）分析
• 是否存在一种虚拟抽象的关系，把两个看起来没有关系的领域关联起来，而这个虚拟抽象的东西可能就是一种共享的高维度的模块

另外有两个重要的技术概念也需要参与分析：低耦合性，高一致性

• 低耦合 ＝ 改变一个模块的代码，不导致需要修改依赖这模块的其他模块的代码
• 高一致性 ＝ 同一个领域的对象，尽可能放在一起并一起发布

还有一个简单的检查，就是通过换位思考，站在一个领域的角度上，判断这个领域词汇应该在什么模块出现、和不应该在什么模块出现。