architecture - DDD - 来自其他有界上下文的验证参考 ID

Question

我有一个关于来自另一个有界上下文的 id 验证的问题。最好用一个例子来解释。我有一个计费上下文和一个仓库上下文。开具发票时，我将产品 ID 附加到商品，然后发送发票事件，以便仓库的上下文发布仓库文档。问题是计费上下文不知道发票行上的产品 ID 是否属于授权用户。我只假设异步通信，因此如果给定用户对给定产品具有权限，我无法询问商店的上下文。

我可以在开具发票后发送事件，在给定用户的上下文中为给定产品开具发票，如果种植有任何问题，我可以发出警报。然而，这似乎不是很令人满意。一年来，我还没有想出任何明智的解决方案来解决这个问题。预先感谢您的帮助。

[EDIT] 我还想指出，我对数据复制不感兴趣，因为我的数据量非常大，类型也非常多。

标签： architecturedomain-driven-designbounded-contexts

Answer 1

数据验证的选项基本上可以归结为：

• 发票上下文询问商店上下文。虽然交互是同步的（因为发票上下文的开具发票过程至少在从商店获得回复时在语义上被阻止），但它与通过异步通道进行的通信并非不兼容（请记住，HTTP 经常在异步通道）：它在很大程度上需要发票上下文能够将发票的状态建模为“已发行但未验证”作为构建和传递到仓库之间的路点。

• 对此的替代方案是发票上下文能够自行跟踪用户可以订购哪些产品，这就是发票上下文需要了解的关于用户的所有信息。请注意，这意味着状态与商店上下文的某些重复，您说您对此不感兴趣（为了完整起见，我将其包括在内）。

• 从您对发票有界上下文的有限描述来看，它可能如此贫乏，它实际上是商店上下文的一部分（如果它执行的验证比您调用的验证多，这可能不是真的），在这种情况下，通过将发票放入存储上下文，您将获得第二个选项“免费”。

• 另一种选择是采用最终的一致性，并且本质上拥有一项服务，可以监视已发布的发票并检查权限。但是，这里的权限验证功能将通过上述方法中的至少一种来执行，所以这样做有点在问问题。

以我的经验，高数据量（虽然不清楚你是在谈论股票（大量数据但可能不会经常变化）还是流量（大量变化））往往是通过 CQRS 和朋友重复的论据，但是你肯定比我更了解你的情况，所以我们会淘汰第二个，第四个不是很令人满意。因此，剩下的就是重新访问域模型以查看发票是否真的是商店的一部分（考虑是否有可能有一张涵盖多个商店的发票）以及将发票上下文中的验证建模为更长的东西是否可行-运行与其他上下文的大量交互。