CQRS - Command Store persisting rule

Question

I have been using the Paramore Brigther to implement CQRS and its Command Store. My question is:

What would the best practice be, is it storing the command before or after the handling method completed? I read here it recommend to do it before but don't we want to not storing the command if the handler fails ?

However i can think of few scenarios where you wish to store the command before/after the hendler method executed:

Case A. if there is IncreaseCreditLimitCommand, and during customer retrieval, customer not found. IMO, we do not want to store this command, do we ?

Case B. if there is IncreaseCreditLimitCommand, and during business validation the customer being denied to increase the limit. IMO, we still want to store this command, don't we?

score 1 · Accepted Answer · answered Mar 05 '19 at 02:55

1

What would the best practice be, is it storing the command before or after the handling method completed? I read here it recommend to do it before but don't we want to not storing the command if the handler fails ?

Why not? If we want to be able to reproduce what happened later, then we also need to be able to reproduce the commands that fail.

The various write ups of the LMAX Disruptor are good reading to do if you are considering a design where persistence of commands is a feature.

answered Mar 05 '19 at 02:55

VoiceOfUnreason

52,766
5
49
91

how does it differ from event store ? As suggested here (microservices.io/patterns/data/event-sourcing.html), we need to store the event if it indeed occurred in the past, meaning the business logic has been 100% successfully executed. If the command store differs from event store, then in what case we need to implement either of both ? and do we replay from the command store or event store ? @VoiceOfUnreason – bet Mar 07 '19 at 04:15

score 0 · Answer 2 · answered Apr 03 '19 at 17:04

I don't know what "Paramore Brigther" is, but I can tell you about DDD and CQRS. These two methodologies are often be used with event-sourcing, because they fit together like pieces of puzzle. In event-sourcing you save events and not commands. It makes a lot of sense since DDD is event driven. I'm not going to explain it more deeper because it's a very large subject, but I think you should consider this approach instead of storing commands. It's going to save you from a lot of design problems in future.

CQRS - Command Store persisting rule

2 Answers2