domain-driven-design - DDD中的上下文映射和限界上下文有什么区别？

Question

我是学习 DDD 概念的新手，但我无法理解某些东西。

1-上下文映射与有界上下文和子域有什么区别？

2-如何识别限界上下文之间的关系？

标签： domain-driven-designsubdomainbounded-contexts

Answer 1

正如评论中所说，这是一个广泛的主题，在 DDD 中非常重要。它是 DDD 的战略部分。无论如何，我会尝试用一个整体的解释来回答你的问题：

---

DDD 是关于理解和提炼我们想要解决的问题的领域。这是一个学习领域、与领域专家交谈的持续过程。所有的人（开发人员、业务人员等）都说同一种语言。这种语言无处不在（对话、文档、源代码……）。它被称为通用语言（UL）。

问题域可能具有不同的功能区域，它们也是域。它们是子域。因此，子域是问题域的子集。这就像将问题拆分为更小的子问题，而子域将是子问题的域。有3种子域：

• 核心：提炼的重点是发现对业务有价值的子域，即能使你的产品比同类产品更好的子域。这样的子域是“核心子域”。例如，在“项目管理”中，“任务分配”将是核心。

• 支持：它专门用于有助于核心功能的某些业务方面。例如，在“项目管理”中，有一个“日历”（用于标记任务交付日期）。

• 通用：任何类型的应用程序都可能需要的功能。例如，用户的认证和授权。

子域属于问题空间。

为了解决这个问题，您对子域进行建模，并创建有界上下文(BC)。实际上，BC 是一个包含子域软件模型的自治应用程序。BC 有自己的 UL。它是 UL 术语具有含义的上下文。UL 和 BC 是 DDD 中最重要的东西。UL 推动 BCs 识别。

理想情况下，您应该将问题空间的子域与解决方案空间的 BC 以 1:1 的比例对齐，即每个子域都应该有一个 BC。

一个团队可以开发一个或多个 BC，但一个 BC 应该由一个团队开发。

BC 属于解空间。

上下文图：它是显示 BC 以及它们之间的关系的图。每个关系都按以下模式之一分类：

• 合伙
• 共享内核
• 客户供应商
• 墨守成规
• 反腐败层
• 开放主机服务
• 出版语言
• 分开的方式
• 大泥球

识别在关系中应用哪种模式取决于您所拥有的特定情况。您必须考虑的一些事项是：

• 两个团队一起合作。
• 其中一支球队不关心另一支球队。
• 团队可以协商。
• 团队是独立的。
• 模型（上游）的更改会影响另一个模型（下游）。