Actually I have very standard approach
commands synchronously are submitted to handlers which use repository and aggregates to submit many events in one commit
So one command can result in many events written to single stream in one commit
This is how it works now - now no commands are logged anyhow.
Recently I started to think how to log user intention
I thought I need to store command even before execution
So I know that user X submitted command Y on time Z.
(I will log token with claims along with command)
Later if aggregate validation passes OK, and if concurrency check will pass the events to event store, I will be able to track from event by it’s commitID back to the command, where I can see the token
It is also possible to log command result - like exception in case it does not pass, or OK in case of success.
Really I am not sure I am doing the right thing, because there will be overhead in logging commands (and possibly command execution result)
But I feel that I should log unsuccessful commands
For example I can build reports saying this was tried so many times and did not succeed
I understand the error log could do this, but I though I will separate out commands as user-intended action log.
Also I started thinking about this because one commit can have many events, and saving token once in “command” log is better - (also it is additional write which is yet another commit)
If logger for command fails - thats not problem because it is just log
Am I doing the right thing?