DDD战略设计--如何确定限界上下文

以下是我们在实际中打成共识的一些经验：

1. 领域专家交流：与领域专家（Domain Expert）密切合作，通过与他们的交流和访谈，深入了解业务领域的不同方面和业务流程。领域专家可以提供关于业务边界、业务规则和业务流程的宝贵信息。

2. 领域知识建模：使用领域知识建模的技术，例如事件风暴（Event Storming）、领域建模会话（Domain Modeling Session）等，团队成员和领域专家共同参与，将领域知识可视化为事件、实体、值对象、聚合等概念，从而识别出潜在的限界上下文。

3. 业务边界和上下文识别：分析业务流程和业务需求，识别出不同的业务边界和业务活动，然后将其映射到相应的限界上下文。每个限界上下文应该有明确的职责和边界，负责特定的业务领域。

4. 概念的一致性和变化频率：观察领域中的概念，根据概念的一致性和变化频率来判断是否需要将其划分为单独的限界上下文。一致性高、变化频率低的概念通常适合作为独立的限界上下文。

5. 可组合性和可复用性：考虑限界上下文之间的可组合性和可复用性。如果一些业务功能可以在多个上下文中共享和复用，那么可以将其定义为共享内核（Shared Kernel）或者单独的限界上下文。

6. 技术和团队结构：考虑技术架构和团队结构的因素，将限界上下文与团队的责任和能力相匹配，以确保团队能够有效地理解和实现相应的上下文。

举一个我们在探索过程中经常用到在线社交平台的一个例子，主要的上下文识别分为以下几种：

1. 用户管理：

   • 负责用户的注册、登录、个人资料管理等操作。
   • 可能包含用户身份验证、权限管理等相关业务逻辑。
   • 交互：提供用户信息给其他上下文使用，例如社交关系上下文可能需要访问用户的个人资料。

2. 社交关系：

   • 负责管理用户之间的社交关系，例如好友关系、关注关系等。
   • 可能包含处理社交关系变更、查找共同兴趣的用户等相关业务逻辑。
   • 交互：可能需要与用户管理上下文交互，获取用户信息和验证用户身份。

3. 内容管理：

   • 负责管理用户发布的内容，例如发表帖子、发布评论等。
   • 可能包含内容审核、内容推荐等相关业务逻辑。
   • 交互：可能需要与用户管理上下文交互，获取用户信息和验证用户身份。

4. 消息通知：

   • 负责发送系统通知、私信等消息给用户。
   • 可能包含消息推送、消息状态跟踪等相关业务逻辑。
   • 交互：可能需要与用户管理上下文交互，获取用户信息和验证用户身份。