How to communicate Domain Events between different Aggregates?

Hi,
just starting out on Axon, so I try to solve the basic problem of communicating domain events between different bounded contexts (i.e. Aggregates, i.e. microservices), not sure If I’m the 114th person asking this, but couldn’t find many helpful leads so far. If someone could nudge me in the right direction, I’d be glad.

  • In an Aggregate A, I have caused what V. Vernon calls “a business-significant occurrence”.
  • Of course, I wish other interested bounded contexts to learn of this event, so they can take what ever action they deem necessary. I therefore issue a record of this fact by publishing a Domain Event.
  • I was hoping to just publish such a domain event wrapped in a message to Axon Server and have it distributed to any other Aggregate that provides an @EventHandler (or something similar) for this event class. This goes along what the Axon Server product page says:

Axon Server has knowledge about the different types of messages that are being exchanged: events, sent from one service to one or many other services, to notify the services that something has happened, commands, sent to one service to do something

But from the documents and discussions I take it that

  • Aggregates can only receive events from THEMSELVES (?!) – Why would I even need a bus/ event store then ?
  • they say I should only send Commands to another Aggregate (see discussion below) – But I don’t want to be coupled to other contexts so tightly, I don’t feel I should have to know what exact state-changing commands will be needed in other business subdomains now or in the distant future. So Command seems the wrong concept here. Domain Event seems exactly right. What is Axons mechanism for that problem?
  • @EventHandler should only be used on the query side (?), i.e. Events in Axon seem to be ment solely to update the Query side from the Command Side – I don’t want to use CQRS, but need a transactionally safe event store and would like to use event sourcing. Is then Axon framework the right choice for me, at all ? Should I just try to use Axon Server ? Should I try to use Axon framework with Kafka instead ?

many thanks
O.

I’ll try to answer your questions briefly in the hope it helps. I think the main problem might be a misunderstanding of what an aggregate is for Axon Framework. An aggregate in Axon servers to make ensure consistent handling of commands, based on the events already send. In order to handle a command message, it might use a snapshot or a cached previous state, append any events belonging to the same aggregate (if there are any), so it’s in the correct state to handle the command message. Typically, handling the command message results in either publishing events message(s) or an exception.

Most applications run with multiple instances, so for the aggregate to get all the events belonging to the aggregate you need something like event bus to get all the events. You also need a command bus, to get the commands to the aggregate. You could also use a state stored aggregate, keep the events just in a local file. But you run into problems as soon as you want to scale out an/or that instance goes down. For commands it’s similar, you don’t want other application needing to know where the application to handle the command is running. You just want to send a command message and have it properly dispatched. Axon Server does a great job on both storing events and routing the messages.

It’s not true you can only send commands to an aggregate. It’s possible to use command messages to do some things directly, not emitting any events. There is always some coupling, and command messages are about making changes. If you just want to notify other services that something has happened, you can send a non domain event. A non-domain event doesn’t belong to an aggregate, and can be send directly to the event gateway.

You can use eventhandlers for a lot of things. You also see them in the aggregate to update the aggregate state. I don’t understand why you would want to jump to Kafka for transactionality, as the transactionality implementation in Kafka is pretty poor.