我们尝试将我们的领域拆分为有界上下文，以实现模块化应用程序设计/架构。
我们做了一个启发性的 EventSorming 会话，它帮助我们识别有界上下文及其聚合。研讨会结束后，每个参与者都同意我们确定的有界上下文。
然而，我们感到不舒服，因为我们担心我们的有限上下文仍然太大。EventStomring 专注于领域事件/流程，这是我们用来识别有界上下文的主要构建块。
我们还确定了诸如“合同”之类的聚合。每个合约几乎都遵循相同的流程，但这些合约包含的数据量可能会有很大差异。有非常简单的合同类型和合同类型，其中包括许多附加数据和附件。
仅仅因为聚合的数据更复杂而声明另一个有界上下文是否有意义？
这两种方法都有其缺点：
任何建议/最佳实践如何处理这个？
...领域事件/过程，这是我们用来识别有界上下文的主要构建块
BCs 不被进程识别，BCs 与语言有关。每个 BC 都有自己的通用语言 (UL)。BC 是概念具有意义的上下文。无论如何，BC属于解决方案空间。首先，您应该探索域（问题空间）并将其拆分为子域，提取核心域。然后为每个子域建模。BC 是模型所在的上下文。理想情况下，子域和 BC 之间的关系是 1:1。
发现子域的过程是迭代的，您会在与专家交谈时更好地了解子域时找到它们。当你发现一个词可能有不同的含义，或者当两个不同的词有相同的含义时，这意味着你正在跨越 BC 之间的边界。
因此，子域识别不是关于流程，而是关于概念和 UL。
仅仅因为聚合的数据更复杂而声明另一个有界上下文是否有意义？
不，您不应该仅仅因为聚合很复杂就任意创建 BC。BC 基于 UL。
任何建议/最佳实践如何处理这个？
您应该通过与领域专家交谈来了解有关领域（合同、类型等）的更多信息，并研究您的聚合（事务一致性）......无论如何，如果您将聚合拆分为其他聚合，这并不意味着它们属于不同的BC，它们仍然可以属于同一个BC。一个 BC 可以有多个聚合。这完全取决于您的具体域。
对我来说，这些迹象表明所有合同都属于同一个业务子域，并且理想情况下应该在同一个限界上下文中——除非遗留系统或第三方系统强迫你这样做。
有界上下文与 if 语句几乎没有关系，所以我不确定你的意思。
限界上下文是一组语义上封闭的业务功能。基本上，如果有界上下文可以完全隔离地执行其功能，即使其他上下文不可用，它也可以很好地定义。
除此之外，您可以在上下文中进行任何设计。我觉得 if 语句的数量更多地取决于您的类/代码设计，例如您是否正确使用多态性、接口等。
但是，就你的观点而言：你不需要第一次就让一切都完美。如果您确定了一些有效的上下文，那么您已经完成了困难的部分。如果可以进一步划分任何上下文，则可能会在以后随时发生，而对其他人几乎没有影响（因为上下文或多或少是孤立的）。