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

11–20 of 86 posts

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

#11

Post by goloroden »

codebeaker wrote: post #9
goloroden wrote: post #7

Earlier quoted context omitted.

Well, yes, there's a certain risk. We had the idea that people liked the word "wolke" (German for "cloud"). Anyway, of course, I would be very happy if you gave wolkenkit a second chance ;-)

I did - reading the brochure now, the word "semantic" keeps cropping up and I wonder if it's an unsympathetic translation from German, or I'm too far away from the JS world to understand that "Semantic" means: > That‘s why we have built wolkenkit, a semantic JavaScript backend that addresses three important aspects of software development, and that empowers you to build better software faster. There's a bunch of thin…

Actually, you're right. What we mean is that it's a backend for JavaScript applications, which itself uses JavaScript.

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

#12

Post by CrystalGamma »

codebeaker wrote: post #6
goloroden wrote: post #3

Hey :-) I'm one of the authors of wolkenkit, so if you have any questions, feel free to ask here :-)

As a non-native German speaker who's lived in Germany for coming up on 10 years, aren't you concerned that it'll be pronounced like "wol-kenkit" not "volkenkit" for non-germans? Naming things is hard but after watching UBER Inc destroy the pronunciation, spelling and etc of a German word, I'm always cautious about unusual names. (Also because, as now I'm hung up on the name before giving your product a fair chance)

To be fair, 'uber' had been in use as an adverb on the internet long before the company stepped on the scene, it's just that now it's in everyone's face …

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

#13

Post by Beltiras »

Yuioup wrote: post #2

Run away. Run far, far away from CQRS and Event Sourcing.

This is the sort of comments that get downvoted usually. You make a blanket statement backing it up with exactly zero characters of evidence or even academic theory. I found thinking in those terms helped me find architecture for webapps that made sense and was extendable and robust. Can you elaborate on why one should stay away?

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

#14

Post by mtarnovan »

Yuioup wrote: post #2

Run away. Run far, far away from CQRS and Event Sourcing.

This comment isn't very helpful.

Still, it should be noted that Fowler warns that CRQS adds significant complexity and advises great caution about using it. See https://martinfowler.com/bliki/CQRS.html

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

#15

Post by 2017Dude »

codebeaker wrote: post #5
Yuioup wrote: post #2

Run away. Run far, far away from CQRS and Event Sourcing.

I'm currently writing a book about CQRS/ES I'd be glad of your notes about it's downsides.

Pragmatic handover of released code and DB to a less technical CRUD team. Avoiding unproven non-anecdotically solutions like EventStore yet still shipping quickly. Avoiding becoming an F#/Scala snob or a JavaScript monkey.

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

#16

Post by he0001 »

While event sourcing is a quite alright tech for certain problems, this idea of "one solution fits all" is just ridiculous. Also the idea of "eventual consistency" is highly situational particularly in an distributed solution. Paradoxically looking at one event source log this looks like a great idea, but there are no guarantees that events propagate evenly and "in-order" so even if events happen and there's "nothing you can do about it", systems will still be out of order, when read in relation to each other because the systems won't know that any other event actually have happened. The system will happily consume it because it won't have the proper info or acted on the wrong information. No matter how you try to mitigate this this will happen and you won't have the slightest idea that it happened. Worst of all, you can't recover from it because the information is gone.

It's just fundamental aspect of asynchronous programming, conveniently forgotten trying to sell solutions.

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

#17

Post by arkh »

codebeaker wrote: post #5
Yuioup wrote: post #2

Run away. Run far, far away from CQRS and Event Sourcing.

I'm currently writing a book about CQRS/ES I'd be glad of your notes about it's downsides.

Workflows for which some steps depends on things: the current real state of an entity, the permissions the current user has etc.

In a client-server system like a web API where you want to respond to the client as fast as possible having to reconstruct your entity from snapshot + some history can take some time. So you end-up with corrective events and responses which are "we have noted your request, poll us to know the result when it's done". The worst is the ES system is already in use in your RDBMS if you use one. Most CQRS + ES demonstration are done with the simple happy path. Rarely something like user A changes the role of user B. User B was saving changes on a document they can't access anymore: what happen?

Now with software on your PC or with a constant link to the server things feel a lot more useful.

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

#18

Post by k__ »

codebeaker wrote: post #5
Yuioup wrote: post #2

Run away. Run far, far away from CQRS and Event Sourcing.

I'm currently writing a book about CQRS/ES I'd be glad of your notes about it's downsides.

I think many people just dislike DDD and CQRS/ES because it's associated with over engineering.

Either you are really good and get things right without much help, which isn't often the case, or you end up in two other directions.

You over-engineer with DDD/CQRS/ES.

You under-engineer without them.

Most developers I met preferred the last solution, probably because they end up with their "own" mess and not the mess of some process.

And I have to admit, the only people I met, that used these techniques, were some "digital transformation" consultants who made their living by selling this stuff to big corps, which isn't too convincing either.

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

#19

Post by EdSharkey »

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.

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

#20

Post by josephg »

he0001 wrote: post #16

While event sourcing is a quite alright tech for certain problems, this idea of "one solution fits all" is just ridiculous. Also the idea of "eventual consistency" is highly situational particularly in an distributed solution. Paradoxically looking at one event source log this looks like a great idea, but there are no guarantees that events propagate evenly and "in-order" so even if events happen and there's "nothing…

This is a problem in how lots of people do event sourcing, but its not a fundamental problem with event sourcing. If you enforce strict ordering of events throughout your stack and do operation catchup properly, these sorts of bugs are completely avoidable.
Post reply on HN