Access web service from CQRS

Question

It is assumed that I have a CQRS-based system, and my domain needs some data from an external web service to make its decisions. How to simulate this correctly?

I can imagine two options:

• The command handler starts the domain logic, and the domain itself calls the web service. Having received the answer, he attaches the corresponding events to the current aggregate and saves them. The domain is basically “waiting” for the web service to return.

• The command handler fires the domain logic, and the domain immediately issues the internal domain event needed for the data. The process manager responds to this, talks to the web service, responds to the result, and creates another command over the previous aggregate, basically something like a continuation.

Which approach is “better” or wrong, and should I follow a completely different approach? Basically, I am fine with option 1, because I think that it’s basically nothing but a long calculation inside the domain, but for some reason the idea of ​​“waiting” annoys me.

What should I do?

Answer 1

I tend to think of my domain as a physical calculator. It accepts input and produces output. This output can either be saved or released as events. Thus, there is some kind of behavior in the data, and the output is data. So it is very focused on behavior.

The script of your option (1) led to several DDD discussions around injection services or repositories (or, I think, the level of anti-corruption) in essence. The general consensus is that it should be avoided and you should choose, say, double sending. The fact is that the domain then needs additional information, and it either has to be transferred initially, or it needs to be extracted. In my calculator, a similar data selection is more like a calculator offering you more input.

If you go with parameter (1), then everything that calls the domain must handle any web call failure in order to retry.

If you go with option (2), where you use something like a service bus and, possibly, a process sorter (for example, a saga or a workflow), it is likely that the service bus handler or process engine will work with errors and repetitions.

I do not think that one solution is necessarily "better" than another, but "different." I would go with what was convenient for you, and if you already have an infrastructure related to failure / repetition, I would go with the option that is most easily supported by this infrastructure.

Hope that helps :)