模块也是一个显式边界，领域模型便存在于边界之内。模块比限界上下文要小，可以做作是限界上下文的子集。
在Java语言中，package是模块的具体实现，package同等于模块，如com.compony.business.xxx。
既然已经有了限界上下文，为何还要有模块呢？
因为，限界上下文的粒度，对于编码实现来说仍然过大，而模块刚好适中。模块天然就被开发语言所支持，如Java的package、C++的namespace。
在一个微服务的代码工程中，domain需要模块、工具类需要模块、service需要模块，等等。
当然，当一个微服务中，因为成本问题迫不得已需要包含多个限界上下文，那么，模块便是这些不同限界上下文的最好的隔离技术手段。
虽然说一个限界上下文中的功能属性是高度内聚的，但是，这个高度内聚的功能属性也是会存在他独有的一面。
举个例子，电商的支付上下文。
支付上下文，有订单支付、有订单退款、有账户转账、有支付安全、有支付账号申请，等等，虽然这一系列的功能，都是与支付强相关，但是这些功能又具有各自的特殊属性。
因此，模块也是这些特殊属性的最好隔离。
现在，你应该明白，DDD为啥需要模块这么个概念了吧？
那么，模块能代替限界上下文吗？
没有了限界上下文，DDD的战略模式是不完整的，没有了模块，DDD只是的战术模式是不完美。
注意的是“完整”与“完美”是两个词。
