在实施DDD的过程中，识别限界上下文是一大难点，但也并非无章可循。在本文内容中，我们将分别从业务维度、工作维度以及技术维度进行展开，讨论如何有效识别限界上下文的方法和技巧。

从业务维度识别限界上下文

从业务维度识别限界上下文的基本思路很明确，就是围绕业务流程的组成结构进行切入。

1. 业务维度的表现形式

业务维度常见的有两种表现形式，即：

1. 流程+角色+活动
2. 角色+行为

我们先来看第一种业务维度的表现形式，如果用图例来展示这种业务维度，可以得到类似下图所示的效果。

在上图中，我们看到业务维度的组成包括流程、角色以及活动三个组成部分，构成了流程+角色+活动的表现形式。随着业务流程的演进，我们可以划分不同的边界并提取不同的限界上下文。而在每个上下文中，我们可以进一步提取多个活动。从这种表现形式看，原本基于某个角色的完整业务流程就被认为切割成多个片段。因此，限界上下文可以被认为是动态的业务流程被边界静态切分的产物。

业务维度的另一种常见表现形式是角色+行为，我们可以使用UML中的用例图来展示这种业务维度，如下图所示。

在上图中，我们看到在A限界上下文中存在多个用例，其中用例4又与另一个B限界上下文发生关联关系。用例描述了业务场景和功能，可以用来提取限界上下文。

1. 业务相关性

当我们通过业务维度识别出若干限界上下文之后，下一步工作是对这些限界上下文进行分析，并判断是否需要考虑对已识别上下文进行优化。这时候就需要引入业务相关性这个概念，因为业务相关性较高的业务逻辑往往应该被合并到同一个限界上下文中。

一般认为，业务相关性有两种类型，即语义相关性和功能相关性。所谓语义相关性，指的是根据名称就能体现业务的相关性，例如浏览商品、发布商品、推荐商品都属于“商品”类的业务。而功能相关性需要根据业务目标来确定，例如推荐商品、活动促销、积分折扣都是为了做“营销”。在基于业务维度识别限界上下文的过程中，你可以根据语义相关性和功能相关性来对上下文进行重新审视。

从工作维度识别限界上下文

从工作维度识别限界上下文跟团队工作相关，是一类依托于管理理念的上下文识别方法。DDD实施过程所崇尚的团队是特征团队。这里引出了一个概念，即特征团队（Feature Team）。我们知道团队的组建方式可以是职能团队也可以是特征团队，前者关注于某一个特定职能，如常见的服务端、前端、数据库、UI等功能团队，而后者则代表一种跨职能（Cross Function）的团队构建方式，团队中包括服务端、前端等各种角色。在DDD工作坊的实施方法中，特征团队的范围更为广泛，可以包含与这个产品和项目相关的所有成员。正常情况下，一个特征团队可以同时应对多个限界上下文的开发需求。因此，判断上下文识别是否合理的标准就是：

一个特征团队是否能够同时开发若干个限界上下文？

从工作维度讲，如果一个特征团队无法同时开发若干个限界上下文，就说明这些限界上下文之间存在较强的依赖关系，边界的拆分不合理，需要进一步识别限界上下文。

从技术维度识别限界上下文

从技术维度识别限界上下文是最符合技术人员的思维方式，我们通过一个示例就可以让你掌握这种识别方法。例如，在电商系统中，我们基于业务维度或工作维度已经成功提取了若干个限界上下文，如下图所示。

现在，我们明确系统需要考虑质量需求，即系统需要应对高并发场景下的商品查询需求。这时候，从技术维度出发，我们就可以专门提取一个实现多元化搜索功能的限界上下文，如下图所示。

接着，我们进一步明确系统需要考虑架构需求，即为了实现技术复用，系统需要在商品、支付、搜索等功能中根据用户画像实现千人千面的商品推荐。显然，从技术维度出发，我们也可以专门提取一个实现推荐功能的限界上下文，如下图所示。

正如前面示例所展示的，基于技术维度的识别方法往往作用于业务维度和工作维度之后，这也符合正常的系统建模顺序，先提炼业务需求再梳理技术需求。

让我们对识别限界上下文的三种方法进行总结，下图可以帮助你更好的理解它们之间的实施方法和特性。