Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Learn what DDD, CQRS, and event-sourcing are all about

docs.wolkenkit.io

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#71

Post by EdSharkey »

bonesss wrote: post #70
EdSharkey wrote: post #69

Earlier quoted context omitted.

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.

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. Unquestione…

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.

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#72

Post by bonesss »

EdSharkey wrote: post #71
bonesss wrote: post #70

Earlier quoted context omitted.

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. Unquestione…

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, 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.

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#73

Post by jorgeleo »

nightski wrote: post #45
jorgeleo wrote: post #28

Earlier quoted context omitted.

It really depends on the application. Eventual consistency means that eventually, the databases will be consistent. Some bank transactions, for example, do not have that luxury because it might allow 2 possible answers to the same query if the eventuality has not been met. Some trading transactions don't have that luxury either because the milliseconds that you waited for the consistency a stock might have changed it…

Banks have daily lag (pending transactions). They also stop business in the evening and resume in the morning to process all these items. That isn't feasible in a lot of scenarios. Rarely do you have an up to the microsecond view of the markets (unless you are located appropriately and pay significant amounts of money). There is always a delay in the information's accuracy and relevancy.

"Banks have daily lag (pending transactions). They also stop business in the evening and resume in the morning to process all these items. That isn't feasible in a lot of scenarios."

I live in the US, and if I got to the ATM and get cash on my account, I can go to my iPhone app and see the transaction and the balance updated.

Yes, there is a nightly process, but not everything is a nightly process.

"Rarely do you have an up to the microsecond view of the markets (unless you are located appropriately and pay significant amounts of money). There is always a delay in the information's accuracy and relevancy."

Do you know what a hedge fund is?

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#74

Post by jorgeleo »

he0001 wrote: post #58
nightski wrote: post #54

Earlier quoted context omitted.

I'd rather argue they are there for "domain" reasons. For one, banks often re-order transactions. I know my bank will process deposits first, then debits for the day. This way you are less likely to incur overdraft fees. It's also to fight fraudulent transactions. Although with the move to "real time" debit processing (which is actually two batch jobs a day) they are placing limits on the types of transactions that c…

They are there because they are used to think that way. It's conways law written all over it... There's no actual reason for them to do it. They replaced their paperwork with a system that does the same thing. Fraudulent transactions can you find without the need of summarizing it. Yes you can do DDD/CQRS without ES but CQRS is not needed, it's just a technical construct not solving any verifiable problem. DDD on the…

Agree, the initial question was on eventual consistency, not on DDD.

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#75

Post by gspetr »

I apologize for making a meta comment, but I had to modify the way the article is displayed because it's an all too common example of this: https://www.wired.com/2016/10/how-the-web-became-unreadable/

Which is very annoying because the article about CSS can't get it's UI right.

They call Svelte "The magical disappearing UI framework" and indeed, their fonts look like they are written in an invisble ink about to dry up.

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#76

Post by gregyoung1 »

jorgeleo wrote: post #28
aaronmu wrote: post #27

Can anyone explain why eventual consistency is so scary? The way I see it, eventual consistency is everywhere. Even in your non-distributed synchronous CRUD app. The minute you start two db transactions within one script you have eventual consistency. You have to deal with the fact that one transaction can fail and that your state can be inconsistent.

It really depends on the application. Eventual consistency means that eventually, the databases will be consistent. Some bank transactions, for example, do not have that luxury because it might allow 2 possible answers to the same query if the eventuality has not been met. Some trading transactions don't have that luxury either because the milliseconds that you waited for the consistency a stock might have changed it…

Bank transactions are eventually consistent. How do you think you can get an overdraft fee? Ever use a gas pump and notice it took a $1 authorization on your card then later settled for what you pumped?

Eventual consistency is not all that scary, try putting on a business hat instead of a technical one. Its about risk management.

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#77

Post by jen20 »

shock wrote: post #43

> 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.

Wrong. Do you seriously think that a cross-bank transfer is operating inside a distributed database transaction? Furthermore, what did banks do before they had computer systems available?

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#78

Post by gregyoung1 »

UK-AL wrote: post #38
victorNicollet wrote: post #37

The DDD/CQRS/ES topic appears on Hacker News every so often, and never fails to stir a strong debate. In fact, I was going to "Show HN" an Event Sourcing library I open sourced yesterday, but I guess I'll wait until everything dies down a bit :-) I believe that the core principles of DDD/CQRS/ES are flawed and are the cause of a lot of pain. If your team plows forward and ignores the pain, you will have a bad experie…

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…

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).

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#79

Post by gregyoung1 »

shock wrote: post #43

> 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.

Bank transactions are usually handled via long running messaging state machines. When as example you transfer from an account in the US to one in Sweden it does not just open a 2PC transaction between the two databases. There are also often intermediaries involved.

Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about

#80

Post by gregyoung1 »

nightski wrote: post #54
he0001 wrote: post #52

Earlier quoted context omitted.

This "lag" is there mostly because historical reasons, not technical.

I'd rather argue they are there for "domain" reasons. For one, banks often re-order transactions. I know my bank will process deposits first, then debits for the day. This way you are less likely to incur overdraft fees. It's also to fight fraudulent transactions. Although with the move to "real time" debit processing (which is actually two batch jobs a day) they are placing limits on the types of transactions that c…

You will also note that they process debits in descending order to maximize possible overdraft fees at most banks ;-)
Post reply on HN