the way I always explain it, is as follows:
What if the external systems was an Axon application as well, and had a proper command handler. What would you have done? Probably have some component, somewhere, send a command, which would end up in that component, which would provide you with a return value. Perhaps they would also send some events that you could be interested in. Would you care about their choice in aggregate boundaries? Most likely not.
But that’s not the world as it is. You can do 2 things. Just stick to their APIs and just call it how you would have done it in a non-Axon application. Or, build a little facade so that, at least from within your application, it looks as if the external system did use commands and events in its API.
In the latter case, you would build a little component that acts as a gateway toward the external system. It translates an incoming command into a Rest call and translates the response to a response of the command. Perhaps, you’re also interested in raising an event, in case a seat was properly reserved. If there is no validation you would need to do, there is actually no need for an aggregate anywhere. You would just have a component with an @CommandHandler, that has a Rest Client and the EventBus injected, and just sends Events when appropriate. Now, from the rest of your system, you can pretend the external system is a nicely designed Axon-based application with a beautiful API ;-).
Oh, the type of component that I just described has a name, in DDD: Anti-Corruption Layer.
Hope this makes sense.
T: +31 6 34 73 99 89