对一个大型的复杂项目而言，模型趋向于越来越大。模型到达了一个作为整体很难讨论的点，理解不同部件之间的关系和交互变得很
困难。基于此原因，很有必要将模型组织进模块。模块被用来作为组织相关概念和任务以便降低复杂性的一种方法。

模块在许多项目中被广泛使用。如果你查看模快包含的内容以及那些模块间的关系，就会很容易从中掌握大型模型的概况。理解了模
型间的交互之后，人们就可以开始处理模块中的细节了。这是管理复杂性的简单有效的方法。

另一个使用模块的原因跟代码质量有关。普遍认为软件代码应该具有高层次的内聚性和低层次的耦合度。虽然内聚开始于类和方法级
别，它也可以应用于模块级别。强烈推荐将高关联度的类分组到一个模块以提供尽可能大的内聚。有很多类型的内聚。最常用到的两
个是通信性内聚和功能性内聚。通信性内聚通常在模块的部件操作相同的数据时使用。把它们分到一组很有意义，因为它们之间存在
很强的关联性。功能性内聚在模块中的部件协同工作以完成定义好的任务时使用。这被认为是最佳的内聚类型。

在设计中使用模块是一种增进内聚和消除耦合的方法。模块应该由在功能上或者逻辑上属于一体的元素构成，以保证内聚。模块应该
具有定义好的接口，这些接口可以被其他的模块访问。最好用访问一个接口的方式替代调用模块中的三个对象，因为这可以降低耦合。
低耦合降低了复杂性并增强了可维护性。当要执行定义好的功能时，模块间仅有极少的连接会让人很容易理解系统是如何工作的，这要
比每个模块同其他的模块间存在许多关联好很多。我们应该选择那些能够表述系统内涵并且包含具有内聚性概念集的模块。这种方式通
常会使得模块之间松耦合，但是如果没有让模型中的概念更加清晰明白，它也能找到一个或许可以作为模块基础的宏观概念，使得各个
元素有机地组合在一起。寻找每一个能够被独立理解和辨别的概念间的低耦合。重定义模型，直到它被按照高级别的领域概念区分开来，
而且对应的代码也被很好地解耦合。给定的模块名称会成为通用语言的组成部分。模块和它们的名字应该能反映对领域的深层理解。

设计人员会习惯地从一开始就创建模块，这在我们的设计过程中是很普通的部分。模块的角色被决定以后通常会保持不变，尽管模块
的内部会发生很多的变化。强烈推荐拥有一些弹性，允许模块随这项目的进展而演化，并且不被冻结。大家都明白模块的重构成本要
比类的重构昂贵的多，但如果一个模块被发现存在设计错误，最好是通过变更模块来定位它，然后再找其他的解决途径。