【DDD 5】领域驱动设计实践 —— 限界上下文识别

喜欢ヅ旅行 2022-03-16 05:12 295阅读 0赞

# [【DDD】领域驱动设计实践 —— 限界上下文识别][DDD_ _] #

**目录**

【DDD】领域驱动设计实践 —— 限界上下文识别

1. 限界上下文（Bounded Context）

2. 上下文图（Context Map）

共享内核（Shared Kernel）

客户/供应商（Customer/Supplier）

Conformist（追随者）

防腐层（Anticorruption Layer）

公开主机服务（Open Host Service）

各行其道（Separate Way）

3. 模式图谱

4. 思考

5. 在COMMUNITY系统中的实践

--------------------

**正文**

本文从战略层面街上DDD中关于限界上下文的相关知识，并以COMMUNITY系统为例子，介绍如何识别上下文。限界上下文（Bounded Context）定义了每个模型的应用范围，在每个Bounded Context中确保领域模型的一致性；上下文图（Context Map）表示各个系统之间关系的总体视图；通过持续集成（Continous Integration）确保多个限界上下文的模型统一。

本文为【DDD】系列文章中的其中一篇，其他内容可参考：[使用领域驱动设计思想实现业务系统][Link 1]。

# 1. 限界上下文（Bounded Context） #

限界上下文（Bounded Context）定义了每个模型的应用范围，在每个Bounded Context中确保领域模型的一致性。不同的限界上下文中，领域模型可以不用保证一致性。通常我们根据团队的组织、软件系统的每个部分的用法及物理表现（如组件划分，数据库模式）来设置模型的边界。

# 2. 上下文图（Context Map） #

多个系统之间会发生关系，存在交互，这也必然会在各自的Bounded Context上有所表现。上下文图（Context Map）便是表示各个系统之间关系的总体视图。在Context Map中可以有如下几种形式来表征限界上下文之间的关系，他们分别是：

## 共享内核（Shared Kernel） ##

当不同团队开发一些紧密相关的应用程序时，团队之间需要进行协调，通常可以将两个团队共享的子集剥离出来形成共享内核（Shared Kernel），双方进行持续集成（Continuous Integration）。由此可见共享内核（Shared Kernel）是业务领域中公共的部分，同时也是团队间容易达成且必须达成共识的领域部分。

## 客户/供应商（Customer/Supplier） ##

不同系统之间存在依赖关系时，下游系统依赖上游系统，下游系统是客户，上游系统是供应商，双方协定好需求，由上游系统完成模型的构建和开发，并交付给下游系统使用，之后进行联调、测试。这种模式建立在团队之间友好合作和支持的情况下。

## Conformist（追随者） ##

如果上游系统不合作，这时候“客户/供应商”模式就不凑效了，那么下游系统只能去追随上游系统，下游系统严格遵从上游系统的模型，简化集成。

例如在COMMUNITY系统中，社区服务的打赏记录来源于支付系统，支付系统的打赏记录这一模型设计较为友好，且社区服务只是一个简单的查询模型，可以直接追随支付系统的打赏记录模型，集成简单快速。

## 防腐层（Anticorruption Layer） ##

如果上游系统的模型不友好，不适合下游系统的场景，但是下游系统又必须依赖于这些模型，这时候我们需要使用防腐层（Anticorruption Layer）模式将上游系统的影响降低。这种模式也是非常常见的，通常出现在系统间对接时，使用trasport+resolver的方式完成服务调用和协议转换。其中的resovler便承担了防腐的作用。

## 公开主机服务（Open Host Service） ##

公开主机服务（Open Host Service）能够允许系统将一组service公开出去公其他系统访问，在互通模型的同时，减少了系统间的耦合。

此类模式是使用最多的。系统之间的交互通常是使用该模式来完成的，而且现在很火的微服务架构也可以理解为此类模式的实现形式。

## 各行其道（Separate Way） ##

当两个系统之间的关系并非必不可少时，两者完全可以彼此独立，各自独立建模，独立发展，互不影响。

# 3. 模式图谱 #

![849051-20170914003436953-629932048.png][]

# 4. 思考 #

综合上述模式，由上而下耦合越来越低，模型的共享程度也越来越低，在实践中，使用得最多的应当是：防腐层 + 公开主机服务的搭配使用。实际开发中，一个上游系统会面对多个下游系统做过多定制化的建模，且由于团队组织和管理上的天然隔离，团队合作的紧密度通常并不会那么高，因此，要做到“共享内核”和“客户/供应商”模式是比较困难的。我认为如今发展的如火如荼的微服务架构便是“防腐层 + 公开主机服务”的实现形式，使用RESTful契约公开主机服务，在业务模型上使用防腐层完成隔离和适配，达到共享模型和降低耦合的平衡。

“共享内核”模式在通用业务领域较为常见，在细分业务领域中，通常由几家厂商抽象出通用的业务模型，并产品化，售卖给各个甲方企业，在实施集成过程中，根据甲方的个性化诉求，在“共享内核”上做二次开发。比如在网上银行这一细分的业务领域中，大小银行的网银系统基本上被科蓝和宇信两家公司承包，且两家公司都已经产品化，具体项目实施时，只需要做一些二次开发，便可快速集成上线。

“客户/供应商”模式个人觉得实施起来会比较困难，毕竟是跨团队协作，及时领头上司是一个，如果这个关键人物不去把控系统设计，那么业务模型上的一致性是很难保证的，最后估计会演变为“防腐层”模式；如果这个关键人物会实际参与到系统建模和设计中，那实际上编程了一个大的团队了，也就无所谓“客户/供应商”模式了，都是自己了。

# 5. 在COMMUNITY系统中的实践 #

结合上述理论知识，及实际实践，我们发现COMMUNITY系统中主要使用到了：“追随者”、“防腐层”、“公开主机服务”三种模式，他们的使用场景分别为：

*  COMMUNITY直接使用支付系统的“打赏记录”模型作为其查询模型，使用到了“追随者”模式；
 *  COMMUNITY访问内容过滤服务，对内容过滤服务的访问模型进行了适配，这里使用到了“防腐层”模式；
 *  COMMUNITY系统通过RESTful服务提供内网服务供其他业务系统内网访问，比如积分系统获取用户的发帖/评论情况等，使用到了“公开主机服务”模式；

综上，我们可以画出COMMUNITY系统的Content Map，如下：

![849051-20170917172030641-1531903786.png][]

[DDD_ _]: https://www.cnblogs.com/daoqidelv/p/7518533.html
[Link 1]: http://www.cnblogs.com/daoqidelv/p/7492322.html
[849051-20170914003436953-629932048.png]: /images/20220316/09d052798f4a46cdadc06a4288af667d.png
[849051-20170917172030641-1531903786.png]: /images/20220316/7877c2d5e7bd473ca7d3f05e457822b3.png