CODEWITHSUNDEEP
architecturedomain-driven-designcqrsevent-sourcing
Lamar
Lamar

Reputation: 641

CQRS - Valid Command Sourcing Use Case?

I am working with a CQRS system that persists commands (with payloads, and success flag).

I have a feature request on the client app to view/rerun past input data that was entered. Since we are storing the command payload, I am wondering if it is reasonable to query the command store for its payload, and then return that payload to the client so it can "auto-fill" the form as if they were going to reissue the command.

I think this means I would have to store the commandId on some read side table/view when the user issues the command. It goes similar to this:

  1. user enters form data
  2. user issues AttachToCollectionCommand which persists the command in a preprocessor
  3. In the handler, the input data is run against some service, then saves the output and collectionId in some table A.
  4. Still in the handler, the commandId (along with a collecitonId) is saved to some other table B.
  5. post-processer updates the command success flag.

Now, later on, when the user opens up that collection, we can load input data (from B) and output data (from A) for each entry of that collection.

My question is if it even makes sense to query this command store for its payload to fill the input data used for a certain member of the collection? Is this a valid use case for this command store? I can see an issue, if inputs eventually change, it will make it more difficult to be backwards compatible.

Thanks

Upvotes: 0

Views: 330

Answers (1)

Brad Irby
Brad Irby

Reputation: 2542

In generic CQRS and Event Sourcing there is no requirement for command storage, just event storage, but there’s nothing barring it either. Therefore, the validity of the use case depends on your business. It’s valid if you think it’s valid.

The issue you see of “if inputs eventually change, it will make it more difficult to be backwards compatible” deserves more than a single sentence. Replaying a command store is similar to automated UI testing. It seems like a panacea at first, but when you get into the details it becomes fragile and difficult to maintain. There are so many things that can happen in your business logic which would invalidate the incoming command that maintaining the replay system would become a job in itself.

My worry about going down this road is user expectation. V1 of the command replay system would be a lot of work but not terribly complicated. The users will love it and want to add features. Then V2 comes along and you have to maintain not only the command replay engine, but add a command transformation engine. That’s a lot of fragile if-then statements to move data around and manipulate it. Then V3 comes and you want to ditch the whole thing because it’s such a time drain but the Users won’t let you.

If you can get users to agree that you will only replay commands from the same release version then things get easier, but that limits the benefits to them since they can’t replay commands from last year’s big Christmas rush.

Command replay is a good idea for QA to repeatedly replay scenarios during testing, but isn’t that really just an integration test? QAs value comes in exploratory testing, not testing the same thing repeatedly.

I’m sorry for the rant. If the users want this feature given the dev and maintenance time requirements, using the stored commands is a valid approach. I would just make sure the requestor is aware of how much maintenance is required each release to keep the thing working. Otherwise you’re throwing away all that effort.

Upvotes: 1

Related Questions