我有一个关于来自另一个有界上下文的 id 验证的问题。最好用例子来解释。 我有一个计费上下文和一个仓库上下文。开具发票时，我将产品 ID 附加到该项目，然后发送发票事件，以便仓库的上下文发出仓库文档。 问题是计费上下文不知道发票行上的产品 ID 是否属于授权用户。我只假设异步通信，因此我无法询问商店的上下文是否给定用户拥有给定产品的权限。
我可以在开具发票后发送一个事件，即在给定用户的上下文中为给定产品开具了发票，如果种植有任何问题，我可以发出警报。然而，似乎并不是很令人满意。 一年来我还没有想出任何明智的解决方案来解决这个问题。 预先感谢您的帮助。
[编辑] 我还想指出的是，我对数据重复不感兴趣，因为我的数据量非常大，类型也非常多。
最佳答案
数据验证的选项基本上可以归结为:
发票上下文询问商店上下文。虽然交互是同步的(因为发票上下文开具发票的过程至少在从商店获取回复时在语义上被阻止)，但它与通过异步 channel 进行通信并不不兼容(请记住，HTTP 通常通过异步 channel ):它很大程度上要求发票上下文能够将发票状态建模为“正在签发但未验证”，作为构建和传递到仓库之间的路径点。
另一种方法是发票上下文能够自行跟踪用户可以订购哪些产品，这就是发票上下文需要了解的有关用户的全部信息。请注意，这意味着存储上下文中存在一些状态重复，您说您对此不感兴趣(为了完整性，我将其包括在内)。
从您对发票有界上下文的有限描述来看，它可能非常贫乏，它实际上是商店上下文的一部分(如果它执行的验证比您调用的验证更多，这可能不是真的)，其中如果将发票放在商店上下文中，您将获得第二个选项“免费”。
另一种选择是拥抱最终一致性，本质上是提供一个监视已发布发票和检查权限的服务。然而，这里的权限验证功能将通过上述方法中的至少一种来执行，因此这样做有点回避问题。
根据我的经验，高数据量(尽管不清楚您是在谈论库存(大量数据，但可能不会经常变化)还是流量(大量变化))往往是通过 CQRS 进行复制的理由还有 friend 们，但是你们肯定比我更了解你们的情况，所以我们就排除第二个，第四个就不太令人满意了。因此，需要重新审视域模型，看看发票是否真的是商店的一部分(如果可以有一张涵盖多个商店的发票，则需要考虑)，以及将发票上下文中的验证建模为更长的内容是否不可行-与其他上下文进行大量交互的运行。
关于architecture - DDD - 来自其他有界上下文的验证引用 ID，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/69145458/