DDD理论学习系列（13）-- 模块

1. 引言

Module，即模块，是指提供特定功能的相对独立的单元。提到模块，你肯定就会想到模块化设计思想，也就是功能的分解和组合。对于简单问题，可以直接构建单一模块的程序。而对于复杂问题，则可以先创建若干个较小的模块，然后将它们组装、链接在一起，从而构成复杂的软件系统。

在DDD中，模块的用途也是如此，通过分解领域模型为不同的模块，以降低领域模型的复杂性，提高领域模型的可读性。

2. DDD中的模块

模块是一个笼统的概念，比较宽泛，为了正确发挥模块的威力，理解模块的概念就十分重要。下面我们从具体的问题着手，来尝试说明模块的概念。

如何对在线商城的顾客进行建模？

对于顾客来说，一般需要维护顾客的个人信息、收货地址、支付方式。这些信息是紧密相关的，不可独立存在。我们可以抽象出三个简单的聚合Customer、AddressBook和 Wallet。那这些类该如何存放呢？是为每一个聚合创建一个文件夹存放还是放在同一个文件夹？我想答案不言而喻。
这三个聚合就是一个模块，一个客户模块。通过定义一个Customer文件夹，来将相关联的领域对象组合起来。而这个文件夹体现在C#中就是命名空间的概念。

再来看一个问题，如何设计在线商城的支付功能？

支付是在线商城中十分重要的一个环节，设计的好坏直接影响项目的成败。一般来说，针对于支付环节，我们应该单独放到支付子域中去处理，以维护领域的不变性，支付环节对应支付上下文，在支付上下文下，一些领域概念才能更清晰。为了提升支付体验，我们势必要支持多种支付方式，比如支付宝支付、微信支付、其他银行卡支付。在对接某一种支付方式时，我们就应该为其定义单独的模块，保证支付方式的独立性。同样，我们可以选择通过命名空间来实现模块化，也可以类似NopCommerce创建单独的项目来插件化开发集成每一种支付方式。同样，我们也可以将整个支付功能拧出一个单独的支付模块，以便在其他项目中进行共用。

如何集成第三方SDK?

我们知道开源的一大好处是，大牛们分享了一系列高效、实用库或软件，也就是大家常说的“轮子”，比如Hangfire、RabbitMQ、Dapper、Redis等等，我们可以直接开箱即用。但如果项目中集成很多的第三方SDK，如果不加以组织整理，项目的结构就会比较混乱，代码的可读性就大大降低。这个时候我们就可以考虑模块化的去集成第三方SDK，通过对第三方SDK的再封装，来完善代码的组织结构，以达到项目中的统一调用。Abp框架就是通过这种方式来集成比较流行第三方SDK。

通过以上的举例说明，我们可以看到模块可大可小，每个模块都是相对独立的功能单元。在C＃中我们可以用命名空间或单独的项目来实现模块。通过模块来组织和封装相关概念，来分解领域模型，以简化领域模型的复杂性。

但不要将模块与子域和限界上下文混淆。在复杂的领域模型中，为了对领域模型中进行准确建模，需要将领域模型拆分成多个子域，每个子域对应一个或多个限界上下文。在限界上下文中，可以将限界上下文中具体的领域概念分解成不同的模块。所以，从子域到限界上下文再到模块，应该是依次包含关系。