4 ms·

Reshaping data is the source of so many costly bugs and communications breakdowns in this world. CQRS is like descending to the 8th circle, pit 7 of reshaping

Reshaping data is the source of so many costly bugs and communications breakdowns in this world. CQRS is like descending to the 8th circle, pit 7 of reshaping hell. What fetish drives one to such tortures? If your schema is any more complicated than a plain stream of characters, and you pick CQRS for your app, then you are an overpaid, bored, architecture astronaut consultant looking to pad his resume. Nevermind the multi-million dollar dumpster fire of an app you spearheaded and ditched out on before completing (and that got cancelled, of course, a complete loss.) If I ever saw CQRS on a resume, I'd unconditionally pass, you're not setting foot in the door.

UK-AL 9y ago
CQRS just simply means your queries, and commands have separate paths. This can be as simple or as complicated as someone wants to make it. It could be as simple as having commands operate on a domain object, but the queries returning a fully populated view object from some custom sql.
- EdSharkey 9y ago
  Are those objects in the queries and queues separate and distinct types then? And, what about the object store, what types go in there? How do we handle data migrations? I like queues as much as the next developer. Queues let you scale performance Mt Everest and deal with concurrency. CQRS as an architecture is like queue abuse.
  - UK-AL 9y ago
    You don't have to use queues, separate objects/NoSQL store or anything like that to use cqrs. I mean you can use them, but all CQRS means is a separate code path for queries and commands. In my system I have command objects, they operate on domain objects which contain some business logic. I have query objects which just execute custom sql code which returns a populated view. This is useful because views often display specific data from multiple domain objects. This system allows you to bring back the entire view in a single query and nothing else, rather trying to retrieve multiple domain objects which are really designed for business rules rather than queries. Often yes, people do starting adding queues, materialised views to CQRS which can make it complicated.
    - EdSharkey 9y ago
      > Often yes, people do starting adding queues, materialised views to CQRS which can make it complicated. You don't say?? You don't say?? Sorry to be flip, I hope you can tell that I've been burned. Badly. Thanks for your detailed response. You obviously care and are not a stupid person nor do you come off sounding vain. But, you're not selling me on CQRS at all. What you've described is just classifications and organization for types in a sane sounding UI design that happen to have similar roles as types in a CQRS system. If you were selling me on CQRS, you'd start by talking about data flow. Something like, "it's a realtime, live multiuser system where all commands are queued, transformed to system events, and those events are committed to log (via another queue, we have to synchronize after all) that stretches back into time. We can replay those events, rewind time, events are merged ..." And it goes on and on into the stratosphere of architecture astronaut-hood... My problem with your response is I honestly can't trust what you say here until I do a code review. Is your actual code pathological, or are you whitewashing the constant twizzling and niggling you have to do to keep your ship afloat? How bad, honestly, do you have to work to add a new feature? What's your velocity like? I want to see how much work and layers there are in your code to do data type transformation. Data transformation is where El Diablo lives, because data transformation requires lots of people to agree and business terms to meet code - it's the unholy marriage of garbage disposal, forest fire, and whirlwind. CQRS seems to invite needless data transforms that other architectures do not require, and that's the pukey taste in my mouth when I have discussions about CQRS.
      - UK-AL 9y ago
        "it's a realtime, live multiuser system where all commands are queued, transformed to system events, and those events are committed to log (via another queue, we have to synchronize after all) that stretches back into time. We can replay those events, rewind time, events are merged ..." And it goes on and on into the stratosphere of architecture astronaut-hood..." But that isn't CQRS. That's event sourcing, a complicated implementation of event sourcing. CQRS can work on a standard SQL system, you can design the database using a standard normalised database. All that has to be different is that commands and queries are separate. A simple implementation; A command can literally be var command= new AcceptOfferCommand(db); command.Execute(); A query can be var query = new AvailableOffersQuery(db); var viewModel = query.Execute() Inside the command you may retrieve a domain object from repository, and execute a method on it. Inside the query method you may just perform a raw sql statement which grabs data from multiple tables, populates a viewModel and returns it. Rather trying to retrieve multiple domain objects from multiple repositories and then shuffling that data into a result.. That's one way of doing simple cqrs. It can be simpler than this. But this code just made it obvious. CQRS allows you do very complicated things, but it doesn't mean you have to.

UK-AL 9y ago

CQRS just simply means your queries, and commands have separate paths. This can be as simple or as complicated as someone wants to make it. It could be as simple as having commands operate on a domain object, but the queries returning a fully populated view object from some custom sql.

EdSharkey 9y ago
Are those objects in the queries and queues separate and distinct types then? And, what about the object store, what types go in there? How do we handle data migrations? I like queues as much as the next developer. Queues let you scale performance Mt Everest and deal with concurrency. CQRS as an architecture is like queue abuse.
- UK-AL 9y ago
  You don't have to use queues, separate objects/NoSQL store or anything like that to use cqrs. I mean you can use them, but all CQRS means is a separate code path for queries and commands. In my system I have command objects, they operate on domain objects which contain some business logic. I have query objects which just execute custom sql code which returns a populated view. This is useful because views often display specific data from multiple domain objects. This system allows you to bring back the entire view in a single query and nothing else, rather trying to retrieve multiple domain objects which are really designed for business rules rather than queries. Often yes, people do starting adding queues, materialised views to CQRS which can make it complicated.
  - EdSharkey 9y ago
    > Often yes, people do starting adding queues, materialised views to CQRS which can make it complicated. You don't say?? You don't say?? Sorry to be flip, I hope you can tell that I've been burned. Badly. Thanks for your detailed response. You obviously care and are not a stupid person nor do you come off sounding vain. But, you're not selling me on CQRS at all. What you've described is just classifications and organization for types in a sane sounding UI design that happen to have similar roles as types in a CQRS system. If you were selling me on CQRS, you'd start by talking about data flow. Something like, "it's a realtime, live multiuser system where all commands are queued, transformed to system events, and those events are committed to log (via another queue, we have to synchronize after all) that stretches back into time. We can replay those events, rewind time, events are merged ..." And it goes on and on into the stratosphere of architecture astronaut-hood... My problem with your response is I honestly can't trust what you say here until I do a code review. Is your actual code pathological, or are you whitewashing the constant twizzling and niggling you have to do to keep your ship afloat? How bad, honestly, do you have to work to add a new feature? What's your velocity like? I want to see how much work and layers there are in your code to do data type transformation. Data transformation is where El Diablo lives, because data transformation requires lots of people to agree and business terms to meet code - it's the unholy marriage of garbage disposal, forest fire, and whirlwind. CQRS seems to invite needless data transforms that other architectures do not require, and that's the pukey taste in my mouth when I have discussions about CQRS.
    - UK-AL 9y ago
      "it's a realtime, live multiuser system where all commands are queued, transformed to system events, and those events are committed to log (via another queue, we have to synchronize after all) that stretches back into time. We can replay those events, rewind time, events are merged ..." And it goes on and on into the stratosphere of architecture astronaut-hood..." But that isn't CQRS. That's event sourcing, a complicated implementation of event sourcing. CQRS can work on a standard SQL system, you can design the database using a standard normalised database. All that has to be different is that commands and queries are separate. A simple implementation; A command can literally be var command= new AcceptOfferCommand(db); command.Execute(); A query can be var query = new AvailableOffersQuery(db); var viewModel = query.Execute() Inside the command you may retrieve a domain object from repository, and execute a method on it. Inside the query method you may just perform a raw sql statement which grabs data from multiple tables, populates a viewModel and returns it. Rather trying to retrieve multiple domain objects from multiple repositories and then shuffling that data into a result.. That's one way of doing simple cqrs. It can be simpler than this. But this code just made it obvious. CQRS allows you do very complicated things, but it doesn't mean you have to.