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