title: Transaction handling in event sourcing
body: <p>I'm trying to wrap my head around transactions in event sourcing.</p>
  
  <p>I have one aggregate (transaction scope) in my event store.</p>
  
  <p>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?</p>
  
  <p>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.</p>
  
  <p>Is this correct thinking?</p>
  
  <p>How is this handled in for instance Kafka and Event Store?</p>
  
  <p>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?</p>
  
  <p>Sorry for the rambling, I hope somebody get what I'm trying to ask here.</p>