识别限界上下文

领域驱动设计围绕着“领域”来开展软件设计。：

1 明确了系统的问题域和业务期望

2 梳理出主要的业务流程，这些业务流程体现了各种参与者在这个过程中通过业务活动共同协作，最终完成具有业务价值的领域功能。参与角色（Who）、业务活动（What）和业务价值（Why）

3 抽象出不同的业务场景，这些业务场景又由多个业务活动组成，我们可以利用前面提到的领域场景分析方法（用例用户故事测试驱动开发）剖析场景，以帮助我们识别业务活动

业务流程是一个由多个用户角色参与的动态过程，而业务场景则是这些用户角色执行业务活动的静态上下文。

以阅读作品场景为例，可以包括如下业务活动：

准确地用统一语言描述出这些业务活动，我们就可以从如下两个方面识别业务边界，进而提炼出初步的限界上下文：

语义相关性：

从语义角度去分析业务活动的描述，倘若是相同的语义，可以作为归类的特征。

语义相关性主要来自于描述业务活动的宾语。

例如，前述业务活动中的查询作品、收藏作品、分享作品、阅读作品都具有“作品”的语义，基于这一特征，我们可以考虑将这些业务活动归为同一类。

细化后的业务活动既能更好地表达领域知识，又能让我们更好地按照语义相关性去寻找业务的边界

注意业务活动之间可能存在不同的语义相关性：

如：

查询作品、阅读作品与撰写作品具有“作品”的语义相关，而评价作品与评价作者又具有“评价”的语义相关，究竟应该以哪个语义为准呢？

没有标准！我们只能按照相关性的耦合程度进行判断。

如果我们将评价视为一个相对独立的限界上下文，则评价作品与评价作者放入评价上下文会更好。

功能相关性：

从功能角度去分析业务活动是否彼此关联和依赖，倘若存在关联和依赖，可以作为归类的特征

倘若两个功能必须同时存在，又或者缺少一个功能，另一个功能是不完整的，则二者就是功能强相关的。

运用用例分析方法，就可以通过用例之间的关系来判别功能相关性

例子：

发布作品与验证作品内容是功能相关的，且属于用例的包含关系，因为如果没有对发布的作品内容进行验证，就不允许发布作品。对于这种强相关的功能，我们通常都会考虑将其归入到同一个限界上下文。

又例如发布作品与设置作品收费模式是功能相关的，但并非强相关，因为设置作品收费模式并非发布作品的前置约束条件，属于用例中的扩展关系。但由于二者还存在语义相关性，因而将其放入到同一个限界上下文中也是合理的。

注意：两个相关的功能未必一定属于同一个限界上下文

购买作品与支付购买费用是功能相关的，且前者依赖于后者，但后者从领域知识的角度判断，却应该分配给支付上下文

为业务边界命名

对业务边界的命名可以算作是对限界上下文识别的一种检验手段。

例如：

如果我们将阅读作品、收藏作品与关注作者、查看作者信息放在一个业务边界内，命名就变得有些棘手了，我们总不可能称呼其为“作品与作者”上下文吧

发布了84 篇原创文章 · 获赞 6 · 访问量 2万+

私信关注