Domain driven design DDD-由于聚合数据不同而导致多个有界上下文？

我们试图将我们的领域划分为有限的上下文，目标是有一个模块化的应用程序设计/架构

我们做了一个启发性的事件分类会议，它帮助我们识别有界上下文及其集合。研讨会结束后，每个参与者都同意我们确定的有界上下文

尽管如此，我们还是感到不舒服，因为我们担心我们的有限环境仍然太大。EventStomring专注于域事件/流程，这是我们用来识别有界上下文的主要构建块

我们还确定了诸如“合同”之类的集合。每个契约几乎遵循相同的过程，但是这些契约包含的数据量可能会有很大差异。有非常简单的合同类型和包含大量附加数据和附件的合同类型

仅仅因为聚合的数据更复杂而声明另一个有界上下文是否有意义

这两种方法都有其缺点：

在一个有界上下文中实现所有契约类型可能会导致代码中出现大量if语句，以便处理不同的数据

仅仅因为某些数据不同，提取新的有界上下文可能会导致大量重复代码

---

有什么建议/最佳实践可以处理这个问题吗？

有界上下文与if语句没有什么关系，所以我不确定你的意思

有界上下文是一组语义上封闭的业务功能。基本上，如果您的有界上下文可以完全隔离地执行其功能，即使其他上下文不可用，它也可以很好地定义

除此之外，您可以在上下文中进行任何设计。我觉得if语句的数量更多地取决于类/代码设计，比如是否正确使用多态性、接口等等

但是，说到你的观点：你不需要在第一次就把每件事都做到完美。如果您确定了一些有效的上下文，那么您已经完成了困难的部分。如果任何上下文可以进一步划分，那么这可能会在以后任何时候发生，对其他上下文几乎没有影响（因为上下文或多或少是孤立的）。

• 没有针对不同类型合同的特定业务团队
• 对于特定类型的合同，没有专门的开发团队
• 所有合同都使用相同的通用语言
• 每个合同几乎都遵循相同的过程

对我来说，这些迹象表明，所有合同都属于同一个业务子域，理想情况下应该处于同一个有界上下文中，除非遗留系统或第三方系统强制您这样做

…域事件/进程，这是我们使用的主要构建块 识别有界上下文

业务连续性不由流程标识，业务连续性与语言相关。每个BC都有自己的通用语言（UL）。BC是概念具有意义的上下文。无论如何，BC属于解决方案空间。首先，你应该探索这个领域（问题空间）并将其划分为子域，提取核心领域。然后对每个子域进行建模。BC是模型所在的上下文。理想情况下，子域和BCs之间的关系为1:1

发现子域的过程是迭代的，你会发现它们，因为你更了解这个领域，与专家交谈。当你发现一个词可能有不同的意思，或者两个不同的词有相同的意思，那么这意味着你正在跨越BCs之间的界限

所以，子域识别不是关于过程，而是关于概念和逻辑

仅仅因为 聚合的数据更复杂

不，不应该仅仅因为聚合很复杂就随意创建BCs。BCs基于UL

有什么建议/最佳做法来处理这个问题吗

---

您应该通过与领域专家交谈来了解更多关于领域（契约、类型等），并研究您的聚合（事务一致性）。。。无论如何，如果将聚合拆分为其他聚合，并不意味着它们属于不同的BC，它们仍然可以属于同一个BC。一个BC可以有多个聚合。这取决于你的具体领域。

谢谢你的回答。所以你认为首先在一个有限的环境中放太多的东西比把可能属于一起的东西分开要好？有点像。我要说的是：迭代！如果您不确定，并且没有立即的需求（没有架构约束或需求），那么现在就不要这样做，推迟这个决定。如果您觉得对于一个上下文来说太多了，比如对于一个团队来说太多的功能无法处理，那么您现在需要拆分。等到一个好的、直接的原因出现。在那之前，要有一个好的内部设计来摆脱你的if-statement。不同类型的合同是由不同的运营团队处理的吗？如果是这样，他们会用不同的词汇来描述他们的工作吗？不一定。问题是，我们的软件只是充当这些合同的“代理”。合同由第三方制定。目前，我们试图将所有这些不同的合同映射到一个结构（模型）来管理它们，这似乎不是一个好主意因此，我们想要分裂事物，但我们不确定这种分裂应该走多远。