Reading this.... It's just like react and redux, combined with redux-sagas. My head is spinning.
Only made 10 years prior.
Show HN: Learn what DDD, CQRS, and event-sourcing are all about
81–86 of 86 posts
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#82> In fact, not even credit institutes work with transactions, they too rely on eventually being consistent. Is this really the case? I was always under the impression that everything regarding financial transactions needed to be transactional.
Consistency here is CAP consistency[1], not ACID consistency. In short, if datum d is visible to Alice at time t1 , it MUST also be visible to Bob at time t2 > t1 . So financial transactions are transactional, but there's no guarantee that every node has a fully up-to-date state at all times. [1]: https://en.wikipedia.org/wiki/CAP_theorem
This is also not how bank transfers work inter-bank. I as Bob (a recipient) may have zero knowledge of a transaction initiated by Alice regardless of time.
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#83Earlier quoted context omitted.
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.
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, uns…
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.
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#84Earlier quoted context omitted.
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.
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, uns…
> 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!
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#85Earlier quoted context omitted.
I could be missing something but I feel like you are inventing an impossible scenario. You may not be making the requirements, but the requirements have to be technically feasible. CQRS/DDD give you a lot of flexibility on where to choose your boundaries/aggregate roots and these are designed around the business/requirements. If you can give a valid scenario where this model breaks down but others would succeed I'd b…
Here's an example from the Wolkenkit brochure: > user.login({ login: 'user', password: 'secret'}); > const isUserLoggedIn = user.isLoggedIn(); If you look at this purely from an API design point of view, this stinks: by forcing the command to return void, the code ends up twisting its design to return the result of the command through an artificial channel (the state of the 'user' object). In the end, we are still in…
Why are you using CQRS for logins? Nothing says derp like "we rolled our own security system"
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#86Earlier quoted context omitted.
Here's an example from the Wolkenkit brochure: > user.login({ login: 'user', password: 'secret'}); > const isUserLoggedIn = user.isLoggedIn(); If you look at this purely from an API design point of view, this stinks: by forcing the command to return void, the code ends up twisting its design to return the result of the command through an artificial channel (the state of the 'user' object). In the end, we are still in…
Why are you using CQRS for logins? Nothing says derp like "we rolled our own security system"
That is a question worth asking, but I don't think it changes the underlying point.