I was, until recently, convinced that the best practice would be to handle all changes to data via CQRS/Axon events.
However, I recently got the idea challenged by others that suggests that Axon only deals with (relevant) business related events.
For instance, would the idea be not to have Axon handle changes to environment specific configuration that is stored in the database.
I also heard suggestions of excluding GDPR sensitive data as that is more complexed with event sourcing.
My concern would be that we don’t get the clear separation of read-and-write model without CQRS. But on the other hand. It doesn’t make much sense to event-source everything (like a configuration).
Whether it makes sense to make every change into an event, is highly dependent on the domain you are in.
If you are in the domain of selling ice cream, having domain specific events about configuration changes might sound a little off.
If the application is however dealing with monitoring and maintaining configurations, it makes total sense to have domain events for these.
Both options could very well reside within the same domain, but I would recommend they would be segregated from one another.
Simply put, think along the lines of having distinct bounded contexts.
Still then, it might not be necessary to publish events for every tiny thing happening within your application.
Having an Event Storming or Event Modelling session with the business would prove beneficial if you would be in doubt here.
In conjunction with all important team members, you should be able to conceive whether something should be an event in your system yes or no.
Short answer to all this? It depends.
That’s my two cents to the situation. Trusting this helps you out Theis!
Cheers,
Steven
PS. It is important to note that this mailing list will be discontinued as specified in this thread.
The thread also specifies where to look further for help when it comes to Axon as soon as this mailing list is closed.
