从CQRS访问Web服务 [英] Accessing a web service from CQRS
问题描述
假设我有一个基于CQRS的系统，并且我的域需要来自外部Web服务的一些数据来做出决定。我如何正确建模呢？
Supposed I have a CQRS-based system and my domain needs some data from an external web service to make its decisions. How do I model this correctly?
我可以想到两个选择：
-
命令处理程序运行域逻辑，并且域本身调出Web服务。获得响应后，它将适当的事件附加到当前聚合并将其存储。域基本上等待 Web服务返回。
The command handler runs the domain logic and the domain itself calls out to the web service. Once it gets a response, it attaches the appropriate events to the current aggregate and stores them. The domain basically "waits" for the web service to return.
命令处理程序运行域逻辑，并且域立即发出域内部的需要更多数据事件。流程管理者对此做出反应，与Web服务对话，对结果做出反应，并在前一个聚合上创建另一个命令，基本上是诸如 continue 之类的东西。
The command handler runs the domain logic and the domain immediately emits a domain-internal more data needed event. A process manager reacts on this, talks to the web service, reacts on the result, and creates another command on the former aggregate, basically something such as continue.
哪种方法更好，或者两者都是错误的，我应该采用完全独立的方法吗？基本上，我对选项1没问题，因为我认为这基本上不过是域内长时间运行的计算，但是以某种方式等待的想法激怒了我。
Which approach is "better", or are both wrong, and I should follow a completely separate way? Basically, I'm fine with option 1, because I think this is basically nothing but a long-running computation inside the domain, but somehow the idea of "waiting" irritates me.
我该怎么办？
推荐答案
我倾向于将自己的领域视为关于物理计算器的领域。它接受输入并产生输出。该输出可以存储或作为事件发出。因此，进去数据时，会发生某些行为，而进出数据。因此，我们非常关注行为。
I tend to think of my domain as I do about a physical calculator. It takes input and produces output. That output can be either stored or emitted as events. So in goes data, some behaviour takes place, and out comes data. So very much focused on behaviour.
您的选择（1）场景导致了有关注入服务或存储库的DDD讨论（或者，我猜是反损坏层）变成实体。普遍的共识是应该避免这种情况，而应该选择两次派遣。关键是该域需要更多信息，并且要么需要首先传递它，要么需要获取它。在我的计算器中，获取更多数据就像是计算器提示您输入更多信息。
Your option (1) scenario has resulted in a couple of DDD discussions around injecting services or repositories (or, I guess, an anti-corruption layer) into entities. The general concensus is that it should be avoided and one should opt for, say, double-dispatch. The point is that the domain then needs more information and it either needs to be passed in initially or it needs to be fetched. In my calculator analogy fetching more data is like the calculator prompting you for more input.
如果您选择选项（1），则调用该域的任何内容都需要处理任何为了重试，网络调用失败。
If you go with option (1) then whatever is calling the domain needs to handle any web-call failure in order to retry.
如果您选择选项（2），则使用诸如服务总线之类的东西，并且可能使用某种流程引擎（例如saga或工作流），服务总线处理程序或流程引擎很有可能会处理故障和重试。
If you go with option (2) where you use something like a service bus and, possibly, a process engine of sorts (say saga or workflow) it is quite likely that the service bus handler or the process engine is going to be handling the failures and retries.
我认为没有一个解决方案必定比其他更好，但不同。我会选择您喜欢的任何方式，如果您已经具有处理故障/重试的基础结构，那么我会选择该基础结构最容易支持的选项。
I don't think one solution is necessarily 'better' than the other but rather 'different'. I'd go with whatever you feel comfortable with and if you have infrastructure dealing with the failure/retry in some way already then I'd go with the option that is most easily supported by that infrastructure.
希望有帮助：）
这篇关于从CQRS访问Web服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
