domain-driven-design - 有界上下文的大小

Question

我已经开始学习 DDD 的原理，目前正在尝试掌握有界上下文的概念。特别是，您如何决定它必须有多大（或小）？是的，我知道，尽可能小，尽可能大（根据 Vaughn Vernon 的说法）。

假设我要为博客建模。然后我可以说涉及 3 个有界上下文：1）首页（包含最新文章，未显示评论） 2）讨论（包括评论的单篇文章） 3）文章撰写者（我撰写文章的地方）。

但是，这感觉不对（无处不在的语言对所有人来说都是相同的），似乎我是从前端的角度来看的，并且仍在考虑视图模型或其他东西。

谁能指出我正确的方向？

Answer 1

博客不是使用多个有界上下文的好例子。这并不是一个真正“足够大”的软件示例来保证他们的定义。DDD & BC 的真正目标是大型/复杂的企业软件系统。

就像您说的那样，在您的 3 个示例中，聚合始终具有相同的含义。

我在之前的答案中给出了这个限界上下文的例子，我希望能解释 BC 以及何时使用它们：Bounded Contexts and Aggregate Roots

Answer 2

尝试从不同的角度看待你的整个领域，作为文章的编辑，你可能会使用诸如创建文章草稿、发表文章之类的句子，作为文章读者，你将阅读文章并对其进行评论。除了构建您的领域语言之外，您还将识别实体及其行为，其中一些只会出现在一个角度，一些会同时出现，但您会通过它们的行为来区分它们。您的领域语言向您展示了每个视角的边界，您将其实现为有界上下文。

Answer 3

到目前为止，我通过子域阅读的最佳示例如下。

只需检查实际的公司！参与业务流程的每个部门都可以有自己的子域。在理想情况下，每个子域在您的实现中都有自己的有界上下文。你应该问问自己公司是否需要一个新部门来做这件事？真的有那么大吗？

BC 必须大到足以描述公司的一个部门。一个典型的例子是网上商店，你有一个购物核心域和发票、交付和存储子域。正如前面的回答所描述的那样，拥有多租户和多个方面是不够的。一个作者和几个读者的博客不需要多个部门，因此您可以使用单个有界上下文来解决这个问题。如果您认为有界上下文中有中等大小的结构，则可以在有界上下文中拥有多个模块。