To commanded or not to?

I don’t want to end up in some strange polemic back-and-forth,
Unless you also store the reason why a command fails, I still don’t see the point of keeping track of them in a persistence store… (in the end, there is still this thing called “logs”, right?)…
Also, I am not sure if I fully agree with “the reality is that most often they [commands] don’t fail”…it reminds me of the statement “The network is always available.”

It is called an aggregate because it aggregates the list of facts that represent the (volatile) state, quite a technical artifact that is usually not so useful when communicating with business people. For that audience, I tend to use “business process” or “behavior”.
Also, the phrase “Would you want us to built your new system based on hopes, rather than facts?”, usually sticks :slight_smile:

1 Like

IMO, Command Sourcing/Replay is necessary for proper Audit Trail and for recording/replaying realistic test scenarios, instead of writing integration tests manually.

I think the simplest solution is for every command to emit a special audit trail event with the command in the payload, or maybe Commanded has some hooks or middleware that allows this to be done without boilerplate code?


Links relevant to this discussion:

Event Sourcing vs Command Sourcing (2013)

Jean Paliès - How video games taught me event sourcing

Game Replay

Command Sourcing

Command Sourcing vs Event Sourcing

2 Likes