下载掌阅APP，畅读海量书库
立即打开
在上一章中，我们已经明确子域和限界上下文都属于DDD战略设计部分的内容，其目的是完成对业务系统的有效拆分和集成。关于如何划分子域的类型以及如何实现限界上下文的集成，业界也存在一组既定的规范和模式。
虽然子域的划分因系统而异，但基于对子域特性和需求的抽象，我们还是可以梳理出通用的分类方法。相比领域，子域对应一个更小的问题域或更小的业务范围，但所有子域的定位和表现形式并不都是一样的，而是有不同的分类。业界比较主流的分类方法认为，系统中各个子域可以分成核心子域、支撑子域和通用子域3种类型。
❑核心子域：代表系统中核心业务的一类子域。
❑支撑子域：专注某一方面业务的一类子域。
❑通用子域：具有公用功能或基础设施能力的一类子域。
为了更好地理解这3种子域之间的区别，这里列举一个示例。在电商类应用中，用户浏览商品，然后在商品列表中选择想要购买的商品并提交订单。而在提交订单的过程中，系统需要对商品和用户账户信息进行验证。从领域的角度分析，我们可以把该系统分成如下3个子域。
1）商品子域：该子域负责商品管理，用户可以查询商品来获取商品详细信息，同时基于商品提交订单；系统管理员可以添加、删除、修改商品信息。
2）订单子域：该子域负责订单管理，用户可以提交订单并查询自己所提交订单的当前状态。
3）用户账户子域：该子域负责用户管理，我们可以通过注册成为系统用户，同时可以修改或删除用户信息，并提供账户有效性验证的入口。
从子域的分类上讲，用户账户子域比较明确，显然应该作为一种通用子域。而订单是电商类系统的核心业务，所以订单子域应该是核心子域。至于商品子域，在这里比较倾向于支撑子域。整个系统的子域划分如图2-1所示。
图2-1 电商类系统的子域分类示例
把领域拆分成多个子域之后，我们也就有了多个限界上下文。随之而来的问题在于如何有效地管理这些限界上下文之间的关联关系，这就涉及本节讨论的话题，即设计上下文的映射关系和集成模式。
1.限界上下文的映射关系
站在高层次的架构分析角度，任何一个系统都可以处在其他系统的上游，也可以位于其他系统的下游，图2-2展示了这层关系。
在图2-2中存在限界上下文A、限界上下文B和限界上下文C。限界上下文A同时位于限界上下文B、C的上游；限界上下文B相对限界上下文A而言处于下游，但相对限界上下文C而言处于上游；限界上下文C则处在整个系统的最下游。
图2-2 上下文映射关系示意图
另外，正如在上一章中讨论的，由于不同的上下文可能由不同的团队来负责实现，在明确诸如图2-2中的上下文映射关系的同时，需要考虑不同开发团队和组织之间的关系。组织关系对团队实施DDD有重要的指导意义。由于涉及系统之间的交互，因此无论是否采用子域和上下文的概念，现实中都普遍存在3种最基本的组织关系，即供应商关系、合作关系以及遵奉者关系。
1）供应商关系。供应商关系是上下游关系的具体体现，客户方依赖供应商提供的服务才能构建自身的系统。供应商关系虽然主流但不是最好的组织关系，因为处于上游的供应商对处于下游的客户方系统影响巨大。
2）合作关系。合作关系指处于上游和下游的两个上下文团队共同进退，双方通过制定合理的开发策略确保上下文集成工作能够顺利开展。合作关系是比较理想的组织关系，尽管系统并不一定具备实现该关系的条件。
3）遵奉者关系。遵奉者关系是我们所不希望看到的，即上游的上下文团队由于利益关系等因素并不希望或没有能力推动系统集成，那下游的上下文团队只能妥协或另谋他路。
2.限界上下文的集成模式
限界上下文集成模式的基本思路有两点，一点是解耦，另一点是统一。解耦比较容易理解，即在两个上下文集成时，一方面考虑技术实现上的依赖性，需要支持异构系统的有效交互，另一方面则需要使专门实现系统集成的过程与实现业务逻辑的过程分离，确保集成机制的独立性。而统一的含义在于一致性，即上游上下文应该定义协议，让所有下游上下文通过协议访问，确保各个上下文在数据传输接口和语义上能够达成一致。
针对以上两点，我们可以分别抽象出两种基本的上下文集成模式，即防腐层和统一协议。
1）防腐层（AntiCorruption Layer，ACL）。防腐层强调位于下游的限界上下文根据领域模型创建单独的一层组件，该层组件完成与上游上下文之间的交互，从而隔离业务逻辑，实现解耦。
2）统一协议（Unified Protocol，UP）。统一协议则指位于上游的限界上下文提供标准且统一的协议定义，从而促使其他上下文通过协议进行访问。
显然，防腐层模式面向下游上下文，而统一协议模式面向上游上下文。在对任何子域和上下文进行提取时，确保从组织关系和集成模式上对上下文的集成过程进行抽象。图2-3即是图2-2所示的上下文关系在集成方案上的一种表现形式。
图2-3 上下文集成模式示意图
结合前面介绍的电商类应用程序的子域划分结果，从子域之间的上下游关系上看，订单子域需要同时依赖商品子域和用户账户子域，商品子域和用户账户子域之间则不存在交互关系。3个子域对应的限界上下文关系如图2-4所示。
图2-4 电商类系统上下文映射和集成示意图
如果我们采用微服务架构来构建这个系统，那么图2-4中的上下文映射关系和集成模式就为我们提取微服务提供了依据。我们完全可以对每个子域分别提取一个微服务，并通过它们之间的映射关系来设计系统的整体交互流程。