领域驱动设计中的子域实际上是什么？

Question

所以我正在读《Vaugh Vernon 的实现领域驱动设计》一书，有些东西我不明白。为了清楚起见，让我们看一下我从书中截取的图片。以下是他如何描述 DDD 概念，例如有界上下文、子域等。

正如您在图片中看到的，它描述了一家零售公司的领域。您有隐式有界上下文，还有有界上下文内的子域，但在进一步阅读了几页后，我发现了这张图片。

所以现在这让我感到困惑，因为在第一张图片中，子域位于有界上下文中，但在第二张图片中，有界上下文位于子域（核心、支持、通用）内部。那么他在第一张图片中描述的实际上是一个子域。和第二张图是同一个东西吗？

Answer 1

您在有界上下文中没有子域。它更像是这样的：

域代表问题空间，有界上下文代表解决方案空间。在软件术语中，这涉及特定问题的解决方案的实现。

每个公司都有一个整体领域，如果该领域具有一定的复杂性，那么该领域通常由不同的子领域组成（这毕竟是选择DDD的原因）。

值得注意的是，这些子域可以分为：

• 核心子域，公司利用其竞争优势赚钱的子域）
• 支持性子域，这些东西并不能真正为最终客户增加价值，但需要实现核心子域的工作，它们也代表了公司的自定义问题，这些问题无法通过市场上现成的实现来解决，
• 通用子域，几个公司都很常见的问题

例如，鲜花网​​上商店作为其核心子域，可以在同一天超快速地交付鲜花。然后，例如，他们的采购可能是一个支持性子域 - 与最终客户无关，但足够复杂和定制，以至于该子域的问题与其他公司不同。他们如何确保客户的网站授权（例如使用 OpenID Connect / OAuth2）将是一个通用子域，他们宁愿使用现成的解决方案，也不会实施自己的身份提供商。

各自的有界上下文只是这些问题（子域）的相应解决方案。尽管子域和有界上下文之间可以存在 1:1 映射，但这并不是必须的。在发现子域的同时，设计和建模有界上下文，以便为问题空间提供最佳解决方案，并定义在系统中有意义的相应边界。

作为开发人员，我们无法选择有哪些子域，这是给定的。但我们可以根据情况的背景和限制，选择如何划分界限，例如进行物理分离或团队开发责任分离。无论哪种方式，我们都需要知道有界上下文定义了语言边界，并且我们必须确保该有界上下文内的语言不存在冲突。

更新：

我想回答附加问题（见评论）：

有界上下文可以存在于 1 个以上的子域中吗？正如您在第二张图中看到的，通用子域内部的有界上下文似乎与其他子域重叠。

我建议您查看图 2.4 以及本书第 2 章“现实世界域和子域”中的相应文本。

在这种情况下，通用子域是 ERP（企业资源规划）。这是一个很好的例子，它可以作为第三方提供商的软件提供，并且可以集成到您的系统中。

相应的有界上下文ERP与库存和采购子域重叠，因为此实现还提供库存和采购 ERP 模块（或 API），允许这些子域使用ERP上下文。

因此，尽管这些特定模块（或 API）满足了支持子域库存和采购的需求，但它们是在 ERP 有限上下文中实现的，而不是在库存和采购有限上下文中实现的。

所以，是的，虽然子域和有界上下文之间的1:1 映射 是可取的，但在实现时，有时可能需要一个有界上下文处理来自多个子域的需求。此外，在遗留系统中通常存在一些限制，不允许您自由地创建有界上下文的最佳设计。