I'm trying to wrap my head around transactions in event sourcing.
I have one aggregate (transaction scope) in my event store.
A command gets processed and is producing 10 events. Now, can this be handled as 1 transaction or is this 10 transactions? With transaction I mean changes to the state that is only valid together as a whole. Have I designed my events wrong if they are split up into many events like this even though I want them to be handled as a whole?
I tend to think that it is the command that is what is defining the transaction, the intent, and that all events produced by that command should be handled together as a whole. Meaning that they should only be persisted as a whole, loaded as a whole, visible to readers as a whole (atomically) and also only sent to listeners on my event bus as a whole.
Is this correct thinking?
How is this handled in for instance Kafka and Event Store?
And what about commands that produce many events, is that really good design? I want something to happen (command) and something happened (event), not many things happened?? I'd like to have this 1:1-relationship but I read here and there that commands should be able to produce many events, but why?
Sorry for the rambling, I hope somebody get what I'm trying to ask here.