假设我们使用 OOP。
子域是一个类吗？限界上下文是一组仅出于目的（理想情况下）一起使用的类？子域上可以包含一组类吗？如果是，那么有界上下文有什么区别？
例如，我们有一个域：在线商店。
我们将在线商店分为 2 个子域：客户支持和购物。
我们看到这样的划分还是很大的，所以我们划分：
可能它不是子域的最佳示例，但重点是让您了解我的问题。
【问题讨论】：
最近我阅读了 Vaughn Vernon 的实施领域驱动设计，我强烈推荐你阅读这本很棒的书。这就是我根据这本书用几句话定义这些概念的方式：
域 - 组织做什么；专业知识和不同的行动。领域是有界上下文作为解决方案的问题。
子域 - 域的一部分。
有界上下文 - 明确的边界与特定的普遍存在的语言。当每个子域都有自己的有界上下文时最好。应该尽可能大，以表达其整个无处不在的语言。
但肯定还有很多话要说。
【讨论】：
我会试着解释一下，你在搞混。
子域：属于问题空间。在这里，您没有课程或任何有关编程语言的内容。你有概念、关系……当你必须解决一个问题时，你就有了那个问题的领域。如果这个问题很广泛，你可以把它分成更小的子问题，这些子问题也是问题。所以子域是子问题的域。
有界上下文：属于解空间。在这里，您确实有类或任何其他编程语言的工件。如果您有问题，BC 是实现和解决该问题的应用程序。您对问题的领域进行建模，这样您就有了领域模型。理想情况下，BC 将 1:1 与子域相关联。
BC 只是一个类还是其中很多，这取决于您将域拆分为子域时的粒度，以及您如何对子域进行建模。 BC 应该有多少个班级没有任何规定。
希望我的解释有所帮助。
【讨论】：
子域可能不是一个类。
<shameless plug>
这是我书中的摘录：
</shameless plug>
域是我们模型关注的总区域。无论域的大小如何，您都很可能会遇到域模型的不同部分属于一起的情况。与大多数事情一样，我们将分而治之。
尽管域中的以下部分根据您对它们的看法而被赋予了特定的名称，但它在很大程度上是学术性的。我们不应该为此分心，如果您开始将域分组为逻辑单元并将每个域称为 子域，那么一开始绝对没问题。
这是您的域的主要部分，最重要。就股票市场的说法而言，这正好属于头条盈利空间。它是您的域的存在理由。这部分必须工作并且必须工作良好，并且是你的系统中一切都围绕着的部分。如果您很难确定这一点，则意味着您拥有一个相当大的核心域。就是这样。
这些有助于以通用方式执行某些任务，并且实现细节对我们的核心领域并不重要。财务会计和计算引擎可以自行购买并用于执行这些功能。
我认为通用子域和支持子域之间经常存在混淆。支持的子域不够通用，您可能会找到任何现成的可用东西。它会非常具体地满足您的业务需求，但仍不属于业务核心。
【讨论】：