每个操作上下文有不同的不变量



如何处理每个操作上下文不同的不变量?想象一下,您有库存微服务和预订功能。现在,保留功能取决于谁在执行操作。如果这是针对出库交货的预订,则只能预订未损坏的项目,如果这是用于内部操作的预订,即Shift,则可以预订。我们目前只有一个名为Reserve的函数。我们是否应该执行不同的储备职能?预留出站,预留换班?那么,如果出现额外的规则,会发生什么呢?保留重新包装,保留缺陷修复?

"it dependent"有一个很强:(

在我继续之前,有必要定义"不变量"一词:不变量是一种业务规则,适用于各种操作,至少适用于实体处于相同状态(如状态机状态(时的各种操作,(非常重要的是(通常是那些定义了定义聚合的直接一致性边界的不变量。。欲了解更多信息,请阅读此处

我建议的第一件事是回到你的中小企业/领域专家那里,看看他们是如何看待事情的:在他们看来,对外交付的预订与内部交付的预订不同吗?他们用不同的名字称呼这两个人吗?他们以后在处理上也有一些不同吗?在这种情况下,我更倾向于相信这是建模过程中的错误,事实上你有两个独立的实体,而不是对单个实体的操作。(参见弗农的文章(。记住,聚合的唯一责任是强制执行这些不变量,如果域专家同意,您可以创建一个聚合来强制执行这个不变量。只需使用命令(同步或从消息总线(推送实例化聚合所需的数据。最有可能的是,如果领域专家将这些视为单独的东西,我也不会惊讶地发现随后也会有差异。

如果这里真的只有一个实体,我个人肯定会将其建模为两个独立的方法。这是很好的OO实践,也是DDD实践。这条规则似乎是对流程和期望的重大偏离,而且由于业务逻辑(有可能使用共享的私有方法(,使用两种方法似乎比将其他方法和数据推送到您的实体中以做出决策要好得多,相反,这是一个外部问题:是你的实体(人类或系统(的消费者在要求内部与外部预订。

至于你担心需要多种方法,我认为与你的领域专家讨论会解决这个问题。

最新更新