undefined | Better HN

0 pointsjakewins4mo ago0 comments

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

0 comments

mexicocitinluez4mo 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.

jakewinsOP4mo 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?

stonemetal124mo ago

Then why the weird assertion that "command" code can only do things and not validate input?

jakewinsOP4mo 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”

Jtsummers4mo 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.

Jtsummers4mo 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.

j / k navigate · click thread line to collapse

0 comments

mexicocitinluez4mo 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.

jakewinsOP4mo ago

The fact that “query” and “ask” are synonyms in English does not make the patterns the same.

stonemetal124mo ago

Then why the weird assertion that "command" code can only do things and not validate input?

jakewinsOP4mo ago

But there’s nothing in the more general idea of “separate reads from writes” that mandates “no validation on writes”

Jtsummers4mo ago

j / k navigate · click thread line to collapse