Is it code smell to use query command inside saga?

Axon Framework
1

Continuing the discussion from Purpose of associationProperty property within @SagaEventHandler:

2

I think there are some assumptions/misconceptions in your question/example @eyal_Iaroslavitz.

First, keep in mind that command-side and query-side synchronization is asynchronous. So it is possible that when querying during event processing, you get stale data.

Also, remember that you can’t query the command side (please do not fall for the tempting attempts to work around that). All the information needed for the saga instance to make a decision on what to do should be part of the event or the saga instance itself.

So when publishing events (from an aggregate or not) that is relevant to a saga, make sure the needed data is inside the event. You can’t just send an id and then query an aggregate from a saga to check its state.

Finally, you don’t send commands to an aggregate. You simply sent a command, period. Who handles that command is determined based on the configuration. So from your saga perspective, it makes absolutely no difference which aggregate will handle a command.

.

1 Like
3

Thank you. So I need to add more data to my events

4

now I see…thank you.

5

I don’t mind see stale data when using command querying inside my saga since all the event driven architecture is based on eventually consistent. Am I missing something here? You see when my saga gets event that was published from Aggregate B and it wants to send command to Aggregate B the data in the event is insufficient I need to get it from somewhere else.
I agree while querying the data might be stale but eventually new command/evet will be published to make the data consistent .

6

Getting data from somewhere else is OK. Even from the query side, if you don’t mind the risk of operating on stale data. However, keep in mind you should avoid long-running operations in your handlers as this will block the entire unit of work. So it is probably better to have a dedicated component that the saga can ask for this information asynchronously (via command, for example). Such a component can then wait, handle timeouts, etc., and finally, send a dedicated event to the saga when the information is available.

1 Like
7

I’ll check it out. Thank you very much

8

So it is probably better to have a dedicated component that the saga can ask for this information asynchronously (via command, for example).

This does not sound right, getting data via command? As I would understand commands should not usually return any results, only identifiers during construction.

9

I think you misinterpreted what I wrote. The command is to ask a component to get the data. It doesn’t return the data as a response to the command. It is up to the component how and when it gets the data. When it is ready it publish an event with the data. The saga processes that event and react accordingly.