如何处理每个操作上下文不同的不变量？想象一下，您有库存微服务和储备功能。现在，该保留功能取决于谁在执行操作。如果这是为外向交货预留，则只能预留未损坏的项目，如果是为内部操作预留，即 Shift，则可以预留。我们目前只有 1 个名为 Reserve 的函数。我们应该实现不同的储备功能吗？ ReserveForOutbound, ReserveForShift?那么如果有额外的规则会发生什么呢？预订重新包装，预订缺陷修复？
【问题讨论】：
“它取决于”是强的一个:)
在我继续之前，有必要定义术语不变量：不变量是一种适用于操作的业务规则，至少在实体处于相同状态时适用于操作（如状态机的状态） ，并且（非常重要）通常是那些定义直接一致性边界的不变量定义了聚合。有关更多信息read here
我建议的第一件事是回到您的 SME/领域专家那里，看看他们是如何看待事情的：在他们眼中，对外交付的预订与内部预订是否不同？他们用不同的名字来指代这两个吗？他们以后在处理上是否也有一些差异？在这种情况下，我更倾向于认为这是建模过程中出现错误的情况，并且您实际上有两个独立的实体，而不是对单个实体进行操作。 （见上面弗农的文章）。请记住，聚合的唯一责任是强制执行这些不变量，如果恰好是领域专家同意的，您可以创建一个聚合来强制执行这个。只需使用命令（同步或来自消息总线）推送实例化聚合所需的数据。很可能如果领域专家将这些视为独立的事物，那么我也不会惊讶地发现随后存在差异。
如果这里真的只有一个实体，我个人肯定会将它建模为两个独立的方法。这是良好的 OO 实践，也是 DDD 实践。这条规则似乎是对流程和期望的重大偏差，并且由于业务逻辑（可能使用共享私有方法）而拥有两种方法似乎比 if-else 和数据推送到您的实体中更好的选择能够做出决定，而这是一个外部问题：您的实体（人或系统）的消费者要求内部或外部预订。
至于您对需要多种方法的担忧，我认为与您的领域专家讨论会解决此问题。
【讨论】：