3 ms·

Sounds really complicated, like "usually badly designed and written code" complicated. GraphQL and Falcor are interesting, and I like the sort of query-as-befi

Sounds really complicated, like "usually badly designed and written code" complicated. GraphQL and Falcor are interesting, and I like the sort of query-as-befits-the-view aspect to working with it. Taking a wait-and-see on those.

bonesss 9y ago
Commands are objects that express a command. A query is something that provides a value. You can code it up in minutes, and most of the code is pure plumbing to connect to datasources. If that sounds complicated to buy independent control over data exchange then you're simply not exposed to the complex multi-layered and distributed applications that demand a structured approach to the issues CQRS handles. Unquestioned and implicit assumptions are great for small potatoes. Domains should model domains and reflect the mental models of the people who work on, and with, the system. If that is experienced as complicating the only conclusion is that you're working with subject material neither complex nor interesting enough to warrant a considered architectural approach. For someone who deals with computing (currying, monads, SOLID, etc), you should know that trying to meaningfully translate superficial domain complexity to generalizations of code quality or design quality of any given solution in all domains is laughable.
- EdSharkey 9y ago
  Laugh away, I'm not interested in flashy code nor resume padding. I am interested in SOLID, clean code. If you have clean code that is easy to add new features to, refactor, and teach to new developers, then good for you. I know good code when I see it. It is clear to me when developers lose sight of the forest for the trees. Your sales technique makes your project sound like torture.
  - bonesss 9y ago
    I'm not selling anything, and you clearly are missing the forest for the trees while making assumptions & assertions about unfamiliar things. CQRS boils down to a single principle: two one-way roads make for easier road maintenance and improvement that one two-way road. Two individual channels are too complicated to code? Torturous? Inherently badly designed? Hard to add new features too? Unclean? ... Crazy talk, unsupported by reality. In fact: CQRS specifically addresses all these points you've brought up through its decoupling. Those kinds of prejudiced assumptions do not hold water, cannot be logically supported by the underlying design nor in-production systems, and reveals only domain ignorance. Successful engineering around distributed Enterprise systems tells a clear story: those maintenance and improvement concerns are predominant at scale. Opinions may vary... Informed opinions on this matter do not.
    - EdSharkey 9y ago
      And now for the coup de grace: you produce a link to sources containing a shining example of CQRS. Truly, one look at this archetypal wonder, (which certainly every programmer worth his salt has already studied its types and patterns at length), and all doubters shall melt away. If there ever were a more killer app demonstrative of the state of the art, it should be the muse of comp-sci journals or even popular culture! A toy Microsoft CQRS spike on github from a couple years back does not count, neither does a book reference. I want a canonical example of something real: deployed code to users, thriving and successful. I'll be a happy to learn something new. My suspicion however is you're all talk - a super-consultant who sold some CQRS work and has an axe to grind because you have co-workers reading this thread, including some of the client's devs. You arrogantly bragged to them and then waded out to sea because you thought me an easy mark to prove your claims to expertise on the subject. I am prepared to gracefully concede to my betters.
    - EdSharkey 9y ago
      > domain ignorance. I suppose I crave simplicity in code, with as little magic as possible, and with as few maddening descents into "not-invented-here" coding adventures when open source modules and frameworks exist that could do the job. My use of the word "clean" refers to Uncle Bob's definition of clean code, not some scientology thing. He preaches the necessity of writing well-tested, high quality code via TDD. You mentioned SOLID earlier, which is another Uncle Bob-ism, and I figured you would get the clean reference. Not Uncle Bob's, but YAGNI's another acronym he likes to throw out there - YAGNI comes to mind whenever CQRS is mentioned. I bet YAGNI would be your worst nightmare if anyone around you had the courage to utter it. Are you a bully or do you just have no scope control on your projects from your business? Hey coworkers of bonesss, challenge everything this guy says with 'YAGNI', and see how he reacts! Yeah, so anyways as I said in my other reply let's see your large scale code example that necessitates CQRS. Impress me with the high quality design and implementation, I'll do a code review. > At scale, under load, while supporting multiple N-tiered applications and their accordant services, unified domain models break down. Aggregate boundaries map these epistemological distinctions. I mean, I get it, you're talking about DDD. You've got context-bounded models. I've explored all this for over a decade. I apply the concepts daily (as mandated by our architecture, not my choice.) In the SOA days we had canonical models that are exposed on the service interfaces and domain-specific models that were representative of data coming from data sources or were internal application specifics and we always mediated between the models. It's nothing special. I sometimes think, if we all talked a little more we could make our terminology more consistent - but I get it, there's domains and different definitions and types will get mapped. What you wrote is too pendantic, though. Epistemological! You're writing web apps, c'mon you are killing me!

bonesss 9y ago

Commands are objects that express a command. A query is something that provides a value. You can code it up in minutes, and most of the code is pure plumbing to connect to datasources. If that sounds complicated to buy independent control over data exchange then you're simply not exposed to the complex multi-layered and distributed applications that demand a structured approach to the issues CQRS handles. Unquestioned and implicit assumptions are great for small potatoes. Domains should model domains and reflect the mental models of the people who work on, and with, the system. If that is experienced as complicating the only conclusion is that you're working with subject material neither complex nor interesting enough to warrant a considered architectural approach. For someone who deals with computing (currying, monads, SOLID, etc), you should know that trying to meaningfully translate superficial domain complexity to generalizations of code quality or design quality of any given solution in all domains is laughable.

EdSharkey 9y ago
Laugh away, I'm not interested in flashy code nor resume padding. I am interested in SOLID, clean code. If you have clean code that is easy to add new features to, refactor, and teach to new developers, then good for you. I know good code when I see it. It is clear to me when developers lose sight of the forest for the trees. Your sales technique makes your project sound like torture.
- bonesss 9y ago
  I'm not selling anything, and you clearly are missing the forest for the trees while making assumptions & assertions about unfamiliar things. CQRS boils down to a single principle: two one-way roads make for easier road maintenance and improvement that one two-way road. Two individual channels are too complicated to code? Torturous? Inherently badly designed? Hard to add new features too? Unclean? ... Crazy talk, unsupported by reality. In fact: CQRS specifically addresses all these points you've brought up through its decoupling. Those kinds of prejudiced assumptions do not hold water, cannot be logically supported by the underlying design nor in-production systems, and reveals only domain ignorance. Successful engineering around distributed Enterprise systems tells a clear story: those maintenance and improvement concerns are predominant at scale. Opinions may vary... Informed opinions on this matter do not.
  - EdSharkey 9y ago
    And now for the coup de grace: you produce a link to sources containing a shining example of CQRS. Truly, one look at this archetypal wonder, (which certainly every programmer worth his salt has already studied its types and patterns at length), and all doubters shall melt away. If there ever were a more killer app demonstrative of the state of the art, it should be the muse of comp-sci journals or even popular culture! A toy Microsoft CQRS spike on github from a couple years back does not count, neither does a book reference. I want a canonical example of something real: deployed code to users, thriving and successful. I'll be a happy to learn something new. My suspicion however is you're all talk - a super-consultant who sold some CQRS work and has an axe to grind because you have co-workers reading this thread, including some of the client's devs. You arrogantly bragged to them and then waded out to sea because you thought me an easy mark to prove your claims to expertise on the subject. I am prepared to gracefully concede to my betters.
  - EdSharkey 9y ago
    > domain ignorance. I suppose I crave simplicity in code, with as little magic as possible, and with as few maddening descents into "not-invented-here" coding adventures when open source modules and frameworks exist that could do the job. My use of the word "clean" refers to Uncle Bob's definition of clean code, not some scientology thing. He preaches the necessity of writing well-tested, high quality code via TDD. You mentioned SOLID earlier, which is another Uncle Bob-ism, and I figured you would get the clean reference. Not Uncle Bob's, but YAGNI's another acronym he likes to throw out there - YAGNI comes to mind whenever CQRS is mentioned. I bet YAGNI would be your worst nightmare if anyone around you had the courage to utter it. Are you a bully or do you just have no scope control on your projects from your business? Hey coworkers of bonesss, challenge everything this guy says with 'YAGNI', and see how he reacts! Yeah, so anyways as I said in my other reply let's see your large scale code example that necessitates CQRS. Impress me with the high quality design and implementation, I'll do a code review. > At scale, under load, while supporting multiple N-tiered applications and their accordant services, unified domain models break down. Aggregate boundaries map these epistemological distinctions. I mean, I get it, you're talking about DDD. You've got context-bounded models. I've explored all this for over a decade. I apply the concepts daily (as mandated by our architecture, not my choice.) In the SOA days we had canonical models that are exposed on the service interfaces and domain-specific models that were representative of data coming from data sources or were internal application specifics and we always mediated between the models. It's nothing special. I sometimes think, if we all talked a little more we could make our terminology more consistent - but I get it, there's domains and different definitions and types will get mapped. What you wrote is too pendantic, though. Epistemological! You're writing web apps, c'mon you are killing me!