这篇文章是一个摘要， 给自己一个关于子域和边界上下文的差异的说明。这些术语通常由域驱动设计从业者使用。曾经有段时间，我把它们混在一起一点点。希望你能发现这个有用。如果你发现任何不准确之处，请告诉我。我仍在改进我的 DDD 实践和知识。

子域

让我们从什么是亚多曼开始。子域位于问题空间中。一个大问题域可以拆分为多个子域。将较大的域划分为较小的子域的原因是，它使管理复杂性更加容易，并且将系统的重要部分与系统的其他部分分开。

等等， 系统的所有部分不是都同样重要吗？

那么，在 DDD 中，子域被分为 3 个类别：

  • 核心域
  • 支持苏多曼
  • 通用苏多曼

核心域

核心域是业务领域最重要的部分。正是它使应用程序首先值得构建。这是从零开始创建应用程序而不是被购买的原因。 这对我们，开发人员意味着什么？这使得我们的业务与众不同（在大多数情况下）。它也可能影响软件是在外部还是内部开发的决定。除此之外，我们应该把大部分的努力在这里，并精心制作系统的这一部分。等等， 系统的所有部分不是都同样重要吗？

值得记住的是，业务可能会随着时间而改变，核心域名也可能会发生变化。敞开心扉，听别人说什么。在初始核心域中度过一段时间后，您可能会找到一个新的域，例如，该域域是从支持子域演变而来的。

支持子域

支持子域术语的支持词意味着此部分支持核心域。换句话说，支持子域提供支持核心域正常功能的功能。这些子域是针对组织和流程的，这就是为什么我们不能购买它们。但是，支持子域比核心域稍重要。这种不那么重要性让我们，开发人员，在质量上投入更少的努力。

不要误会我的意思， 你不应该使用所有反模式， 你知道在支持子域。问题是，软件系统将要解决的问题中越来越不重要的部分。因此，如果有必要，在这里做一些妥协是可以接受的。例如，由于时间压力或其他驱动因素存在于您的环境中。

通用子域

通用子域是业务流程的重要组成部分，但是，这些并非独一无二。因此，可以购买通用子域。一个很好的例子是发信，付款，电子邮件发送服务。如果您的业务不处理这些事情（因为那样它将成为核心领域），那么购买开箱即用的解决方案并将其集成的可能性就更大了。此外，在内部开发通用子域名可能不会给您的业务带来核心域名带来的竞争优势。但是，如果您决定在内部开发通用域，随着时间的推移，它可能会变成核心域。至少根据:D理论。或者一个一开始听起来很棒的想法也可能变成噩梦。想想定制的 ORM … …

绑定上下文

边界上下文位于解决方案空间中。它们通过在代码中明确定义模型责任的界限，帮助在特定上下文中维护域模型的完整性。原因是某些事情可能有不同的含义。例如，客户可能以其名称、年龄、用户名等为上下文进行描述。在付款上下文中，仅用标识符和信用卡号来描述同一客户。 有界限的语境有语言障碍 （是的， 语言很重要， 即使对我们来说， 极客😄） 。该语言来自域专家，应反映在我们的代表域模型的代码中。在给定的边界范围内，术语的定义是明确的。如提到的客户可能意味着两个不同的情况在两个不同的上下文。问题是…你必须抓住这些差异。 怎么做到的？ 对我有效的是听域名专家和学习他们的语言。我还记住他们正在处理或谈论的流程的哪一部分。或者实际上我试图抓住它。除此之外，如果我不明白什么，或者我不确定他们在讨论中在想什么，我会问问题。你需要找到你的方式。

边界上下文边界

正如我提到的，我试图保持我的边界上下文之间的明确界限。同样重要的是，每个 BC 都有自己的域名模型，它不与其他 BC 共享任何数据。例如，只有一个BC负责客户的信用卡号码主要。 换句话说，BC 应该是自主的。自主性意味着可以做决定。

Bcs 很重要

为什么我认为 Bcs 很重要？在几个项目中，我看到模型有问题。除了贫血，这些模型还保存了太多的数据。数据通常与同一个词有关，但在使用此单词的不同上下文中。这导致了真正难以改变的课程，因为改变一件事往往会破坏其他事情。这是因为数据在不同级别上耦合。此外，BC 与问题子域密切相关。根据我的经验，每个问题域保持一个 BC 通常非常有效。理由是，当时班级只有一个改变的理由。这实际上是我认为遵循 Srp 。此外，我尝试制作模型做一件事，并做好它（最好是快速😄）。

一个模型来统治他们呢？

一个模型来统治他们看起来都不是一个好的方法。我体验到，如果需要，最好制作 3 或 4 个客户类。每个都以它自己的语境。让它做它必须做的那件小事。没有更多，没有更少。当复杂的系统被拆分为具有清晰边界的多个代码模型时，维护复杂的系统就更容易了。有了一个大（ger）模型，将错误的概念组合在一起就更容易了。

其他好处

我发现在人与人之间分配工作更容易。在不列颠哥伦比亚省工作要容易得多。我们不太可能同时修改相同的东西。

总结

  • 子域位于问题空间中
  • 有3类子域：
    • 核心
    • 支持
    • 通用
  • 核心子域是应该投入大部分建模时间的地方
  • 边界上下文是答案，是问题空间的解决方案
  • 一个实体（如客户）可能在多个绑定上下文中表示
  • 该解决方案受益于自主 BCs
  • 一个模型来统治它们可能不是复杂应用程序的最佳选择（但它可能有利于 CRUD）