3 ms·

I think CQRS is something different than what’s being described here. “Query” code in CQRS can still “do stuff”: call an external database, grab locks, audit tr

I think CQRS is something different than what’s being described here. “Query” code in CQRS can still “do stuff”: call an external database, grab locks, audit trail recording etc. What’s being described here is something lower level, that you keep as much code as you can as a side-effect-free “pure functional core”. That pattern is useful both for the “command” and “query” side of a CQRS system, and is not the same thing as CQRS

mexicocitinluez 1y ago
It's not about literally doing things (ie logging) it's about the intent. Query and ask are synonyms and represent the same idea in this context.
- jakewins 1y ago
  The fact that “query” and “ask” are synonyms in English does not make the patterns the same. The key design goal in this thread was to create a pure functional core, which you can “ask” things of. That pattern is useful on both the command and query side of a CQRS system, and a different thing from splitting up mutating and reading operations as CQRS proposes Maybe I misunderstand you though. Say you have a CQRS system that reads and writes to a database. Are you proposing the query side be implemented in pure side-effect-free functional code? How should the pure code make the network calls to the database?
- stonemetal12 1y ago
  Then why the weird assertion that "command" code can only do things and not validate input?
  - Jtsummers 1y ago
    Commands can validate their input in CQS. What they don't do, in strict CQS, is return values. They can set state which can then be queried after execution which can let you retrieve an updated result or check to see if an error occurred during execution or whatever.
  - jakewins 1y ago
    That is not something that’s necessary for all CQRS systems, but maybe is something you’ve heard for the subset that people call “Event Sourcing”? There it’s a design goal that the system only records events that are occurring, so there’s no domain level validation that can be done on the command path - the user pressed the button whether we like it or not, so to speak. Whether the event has the intended effect is worked out after the event is recorded. But there’s nothing in the more general idea of “separate reads from writes” that mandates “no validation on writes”
Jtsummers 1y ago
If by "described here" you mean the article, yes, it is not about CQRS or CQS. I was responding to hinkley who was referencing CQS as defined by (or at least popularized by) Meyer in his Eiffel language and books on OO programming.

mexicocitinluez 1y ago

It's not about literally doing things (ie logging) it's about the intent. Query and ask are synonyms and represent the same idea in this context.

jakewins 1y ago
The fact that “query” and “ask” are synonyms in English does not make the patterns the same. The key design goal in this thread was to create a pure functional core, which you can “ask” things of. That pattern is useful on both the command and query side of a CQRS system, and a different thing from splitting up mutating and reading operations as CQRS proposes Maybe I misunderstand you though. Say you have a CQRS system that reads and writes to a database. Are you proposing the query side be implemented in pure side-effect-free functional code? How should the pure code make the network calls to the database?
stonemetal12 1y ago
Then why the weird assertion that "command" code can only do things and not validate input?
- Jtsummers 1y ago
  Commands can validate their input in CQS. What they don't do, in strict CQS, is return values. They can set state which can then be queried after execution which can let you retrieve an updated result or check to see if an error occurred during execution or whatever.
- jakewins 1y ago
  That is not something that’s necessary for all CQRS systems, but maybe is something you’ve heard for the subset that people call “Event Sourcing”? There it’s a design goal that the system only records events that are occurring, so there’s no domain level validation that can be done on the command path - the user pressed the button whether we like it or not, so to speak. Whether the event has the intended effect is worked out after the event is recorded. But there’s nothing in the more general idea of “separate reads from writes” that mandates “no validation on writes”

Jtsummers 1y ago

If by "described here" you mean the article, yes, it is not about CQRS or CQS. I was responding to hinkley who was referencing CQS as defined by (or at least popularized by) Meyer in his Eiffel language and books on OO programming.