1
votes

I'm working on a Axon 3 based application and wondering what would be the preferred way to handle events from external systems or services.
Imagine a situation like this: I ask another services to do something for me and the answer to this something can be interpreted as an event and handled by a saga.

Now I can think of 2 options to handle this event:

  1. Transform the response into a command and apply an event, but in this case you would have a command like MarkSomethingHappendCommand and a SomethingHappendEvent. And you need an aggregate to handle this.
  2. Use an EventStore instance in the response handler, transform the response to an SomethingHappendEvent and do a eventStore.publish(event) to active the saga to continue processing.

Would it be valid, from a Axon Framework perspective, to use the eventbus directly to publish events like this? Would this way also prevent timing issues, like the response from the other service is quicker than committing the UOW from which the call originated?

Thank you in advance!

1

1 Answers

1
votes

First and foremost I'd like to point out that you're thus dealing with Events from another Bounded Context, which you are pulling into your main application (again, a different Bounded Context).

When it comes to the "spoken language", a.k.a. the Messages/API within a Bounded Context, everything should be public knowledge. Between Bounded Contexts, you should however share consciously.

Knowing this, I would definitely suggest to translate the external service event into an entirely different message(/object) within your own application. Whether you translate this into a command or an event highly depends on what this external-service-event describes. A name you could give to this "translation layer" would be the Anti-Corruption Layer, who's goal it is to ensure your local application/context is not corrupted by outside information.

When it comes to the two options you've provided, I'd like to share the following.

Be aware that you do not necessarily have to point a command towards an Aggregate. Command Handlers can just as well be added to beans for example (as is shown https://docs.axoniq.io/reference-guide/implementing-domain-logic/command-handling/external-command-handler). Thus, if your translation operation specifies the external-event becomes a command, this command can go to any service to handle the operation.

When it comes to directly publishing events, I can state it is perfectly fine to do this. Ordering wise, Axon will always check whether a Current Unit of Work is underway when dispatching a message. If so, publication of events will be staged in order. I'd thus not assume immediate timing issues here, although this might depend slightly on what your implementation looks like of course.

Concluding, I'd like to point out that Axon 4.2 has been release a couple of weeks ago, with 4.0 almost being one year old. As such, there is no active development taking place on Axon 3.x, which leads me to suggest that you'd update your Axon version if possible.