4 ms·

I'm CQRS advocate. None of are weakening the CQRS. CQRS is in fact pretty damn lose. "There is a single data model shared by both commands and queries." - Noth

by UK-AL 9y ago

I'm CQRS advocate. None of are weakening the CQRS. CQRS is in fact pretty damn lose. "There is a single data model shared by both commands and queries." - Nothing wrong with that, especially in simple cases. "Commands can sometimes return data" - Well commands can succeed or fail. Greg young himself admits commands are really synchronous, and you need to communicate that. "and no eventual consistency at the aggregate level." - This is the recommended approach. Between aggregates and it becomes loser. "Materialized views for each aggregate are kept in-memory at all times" - Thats some advanced CQRS usage there.

gregyoung1 9y ago
I will speak for myself. Commands are by definition synchronous and return a success/failure. One of my favourite read models to use is an in memory model providing I can keep all of the data in memory (and its reasonable for the query patterns).
victorNicollet 9y ago
Maybe I'm not as much of a heretic as I thought I would be :-)
- UK-AL 9y ago
  Starting from fresh these days I would use something 2 way for commands, queries like HTTP REST. But a messaging system for events. If i'm using event sourcing use a dedicated event sourcing database with catchup subscriptions etc
  - codebeaker 9y ago
    > a dedicated event sourcing database with catchup subscriptions etc Can you recommend any?
    - slashdotdash 9y ago
      Greg Young's Event Store[1]. [1] https://geteventstore.com https://geteventstore.com
    - victorNicollet 9y ago
      We're rolling our own: https://github.com/Lokad/AzureEventStore https://github.com/Lokad/AzureEventStore
tepe1 9y ago
That write-up sounds absolutely terrifying. I really fear for what the .NET community might be doing with event sourcing. Event sourcing is the definitive way to write high-performance front-office trading systems. Nothing else comes close to being able to quickly capture the rich domain of finance and satisfy stringent performance requirements. But what that article describes is unlike any system I've seen in 15 years of fintech work. It's very clear that something has been lost in translation. I suspect the people are coming into this without having the solid foundation in event-driven architecture or high-performance messaging models. As UK-AL points out everything you wrote is standard ES best practices. How is it even possible for a single aggregate to be "eventually consistent"? Aggregates by definition are atomically updated from one valid state to the next. Of course commands should return not just success/failure information but new information that is relevant to the sender (eg, OrderIDs for the Orders created). There's absolutely no reason to make the sender poll an event stream or "view." "There is a single data model shared by both commands and queries." -- In the finance world this is impossible. Execution systems must be separated from reporting systems. And once you make this separation the whole CQRS-aspect naturally falls out. It makes sense, for example, to keep all orders in something like Cassandra or VoltDB for reporting though you'd never do that for execution. The thing is, CQRS is not an end to itself. I'm not sure why it has blown up in the .NET world. Again, something has been lost here. The CQRS tactic is required only when reporting requirements and execution requirements are fundamentally different/incompatible. An EDA makes CQRS-style separation possible but it does not require it. And here's the thing: if you have your end-points designed correctly it's trivial to separate out querying if it's needed. Just model your system using events and aggregates and it should work out. I wasn't even going to comment on this thread. Most of the comments here are your typical HN nonsense -- a potent mixture of ignorance and anti-innovation FUD. But your link to the writeup was enlightening (and horrifying) if only to reveal how people can go very wrong with this "new" architectural style. (Again, event-sourcing, and EDA in general, has been de rigeur in finance since the 80s.)

by UK-AL 9y ago

gregyoung1 9y ago

I will speak for myself. Commands are by definition synchronous and return a success/failure. One of my favourite read models to use is an in memory model providing I can keep all of the data in memory (and its reasonable for the query patterns).

victorNicollet 9y ago

Maybe I'm not as much of a heretic as I thought I would be :-)

UK-AL 9y ago
Starting from fresh these days I would use something 2 way for commands, queries like HTTP REST. But a messaging system for events. If i'm using event sourcing use a dedicated event sourcing database with catchup subscriptions etc
- codebeaker 9y ago
  > a dedicated event sourcing database with catchup subscriptions etc Can you recommend any?
  - slashdotdash 9y ago
    Greg Young's Event Store[1]. [1] https://geteventstore.com https://geteventstore.com
  - victorNicollet 9y ago
    We're rolling our own: https://github.com/Lokad/AzureEventStore https://github.com/Lokad/AzureEventStore

tepe1 9y ago

That write-up sounds absolutely terrifying. I really fear for what the .NET community might be doing with event sourcing. Event sourcing is the definitive way to write high-performance front-office trading systems. Nothing else comes close to being able to quickly capture the rich domain of finance and satisfy stringent performance requirements. But what that article describes is unlike any system I've seen in 15 years of fintech work. It's very clear that something has been lost in translation. I suspect the people are coming into this without having the solid foundation in event-driven architecture or high-performance messaging models. As UK-AL points out everything you wrote is standard ES best practices. How is it even possible for a single aggregate to be "eventually consistent"? Aggregates by definition are atomically updated from one valid state to the next. Of course commands should return not just success/failure information but new information that is relevant to the sender (eg, OrderIDs for the Orders created). There's absolutely no reason to make the sender poll an event stream or "view." "There is a single data model shared by both commands and queries." -- In the finance world this is impossible. Execution systems must be separated from reporting systems. And once you make this separation the whole CQRS-aspect naturally falls out. It makes sense, for example, to keep all orders in something like Cassandra or VoltDB for reporting though you'd never do that for execution. The thing is, CQRS is not an end to itself. I'm not sure why it has blown up in the .NET world. Again, something has been lost here. The CQRS tactic is required only when reporting requirements and execution requirements are fundamentally different/incompatible. An EDA makes CQRS-style separation possible but it does not require it. And here's the thing: if you have your end-points designed correctly it's trivial to separate out querying if it's needed. Just model your system using events and aggregates and it should work out. I wasn't even going to comment on this thread. Most of the comments here are your typical HN nonsense -- a potent mixture of ignorance and anti-innovation FUD. But your link to the writeup was enlightening (and horrifying) if only to reveal how people can go very wrong with this "new" architectural style. (Again, event-sourcing, and EDA in general, has been de rigeur in finance since the 80s.)