4 ms·

My bullshit detector was tripped by the number of buzzwords. What does this actually solve versus say traditional MQ (EIP stuff), service bus systems and norma

by bananas 13y ago

My bullshit detector was tripped by the number of buzzwords. What does this actually solve versus say traditional MQ (EIP stuff), service bus systems and normal SOA? I've dealt with NServiceBus extensively and really big scale .Net stuff and if it's anything remotely close to that architecture, I'd rather hang myself than use it again.

aliostad 13y ago
Yes, so many buzzwords together - I admit. The difference is replacing Commnad/Query with events. Replacing Imperative with Reactive. Did you read the whole post or you were put off by the buzzwords?
- bananas 13y ago
  Perhaps it's because it is Sunday but I phased out after the first couple of paragraphs. I've read it now and am still unaware of why this is fundamentally better. Command/Query pattern is an imeplementation concern. The architectural pattern that backs it up isn't necessarily related (for example event sourcing). At that point it isn't imperative so why is this different? It just appears to be fragmenting lots of concerns into even smaller ones which are vastly more complicated to debug and manage. The bold highlighted text of: "in a reactive actor system, each actor only knows about its own Step and what itself does and has no clue about the next steps or the rest of the system" Isn't that the same for a message channel but without a transactional guarantee? (going back a decade or more to EIP).
  - aliostad 13y ago
    No it is not the same. First of all, CQRS is applying CQS to the architecture, so it is an architectural decision. When you use commands, you know about the interface of the endpoint receiving your message. In case of an event, you do not have to know anything - and this is the whole premise of this post. In the article to come, I have explained the differences more with regard to EIP as well. A half-draft available at https://gist.github.com/aliostad/55b652e44dfe87d44444 https://gist.github.com/aliostad/55b652e44dfe87d44444
    - bananas 13y ago
      Thanks. I'm sceptical (having been through several similar systems and ripped them out) but I will read your draft later.

by bananas 13y ago

aliostad 13y ago

Yes, so many buzzwords together - I admit. The difference is replacing Commnad/Query with events. Replacing Imperative with Reactive. Did you read the whole post or you were put off by the buzzwords?

bananas 13y ago
Perhaps it's because it is Sunday but I phased out after the first couple of paragraphs. I've read it now and am still unaware of why this is fundamentally better. Command/Query pattern is an imeplementation concern. The architectural pattern that backs it up isn't necessarily related (for example event sourcing). At that point it isn't imperative so why is this different? It just appears to be fragmenting lots of concerns into even smaller ones which are vastly more complicated to debug and manage. The bold highlighted text of: "in a reactive actor system, each actor only knows about its own Step and what itself does and has no clue about the next steps or the rest of the system" Isn't that the same for a message channel but without a transactional guarantee? (going back a decade or more to EIP).
- aliostad 13y ago
  No it is not the same. First of all, CQRS is applying CQS to the architecture, so it is an architectural decision. When you use commands, you know about the interface of the endpoint receiving your message. In case of an event, you do not have to know anything - and this is the whole premise of this post. In the article to come, I have explained the differences more with regard to EIP as well. A half-draft available at https://gist.github.com/aliostad/55b652e44dfe87d44444 https://gist.github.com/aliostad/55b652e44dfe87d44444
  - bananas 13y ago
    Thanks. I'm sceptical (having been through several similar systems and ripped them out) but I will read your draft later.