Offtopic, but was the PDF typeset with layouting software or a markup converter such as Pandoc and the like? Looks really slick, kudos. Also is there a way to tell by PDF metadata?
Edit: Had a second look and it's layouting software
Show HN: Learn what DDD, CQRS, and event-sourcing are all about
41–50 of 86 posts
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#42Earlier quoted context omitted.
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…
Maybe I'm not as much of a heretic as I thought I would be :-)
Starting from fresh these days I would use something 2 way for commands, queries like HTTP REST.
But a messaging system for events.
If i'm using event sourcing use a dedicated event sourcing database with catchup subscriptions etc
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#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.
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#44Earlier quoted context omitted.
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.
Well that's the entire problem, you are not the one making the requirements, the solution of the problem does... You can't eat dinner before you have made it. Edit: I would argue that you can't write a system which is open (several domains) and believe that you will have entirely independent events throughout the system and claim that your system will be "bugfree"/correct.
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 be very interested.
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#45Can 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…
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.
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#46Earlier quoted context omitted.
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.
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 displa…
> 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.
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#47Hey :-) I'm one of the authors of wolkenkit, so if you have any questions, feel free to ask here :-)
Can you explain in one or two sentences what wolkenkit is doing exactly? From scrolling through the docs it sort of looks like meteor but with a different data model?
What is your reasoning for AGPL - it's a no-go for
a) indie developers because they can't afford the enterprise stack which is presumably not AGPL
b) enterprises because immediately expect a huge price tag
And last but not least: Why is this not platform agnostic (e.g. only node)?
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#48> 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.
write a check
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#49Earlier quoted context omitted.
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 displa…
> 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 organ…
"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();
var query = new AvailableOffersQuery(db);
var viewModel = query.Execute()
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.
Re: Show HN: Learn what DDD, CQRS, and event-sourcing are all about
#50The 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…
That write-up sounds absolutely terrifying. I really fear for what the .NET community might be doing with event sourcing.
Event sourcing is the definitive way to write high-performance front-office trading systems. Nothing else comes close to being able to quickly capture the rich domain of finance and satisfy stringent performance requirements.
But what that article describes is unlike any system I've seen in 15 years of fintech work. It's very clear that something has been lost in translation. I suspect the people are coming into this without having the solid foundation in event-driven architecture or high-performance messaging models.
As UK-AL points out everything you wrote is standard ES best practices. How is it even possible for a single aggregate to be "eventually consistent"? Aggregates by definition are atomically updated from one valid state to the next. Of course commands should return not just success/failure information but new information that is relevant to the sender (eg, OrderIDs for the Orders created). There's absolutely no reason to make the sender poll an event stream or "view."
"There is a single data model shared by both commands and queries." -- In the finance world this is impossible. Execution systems must be separated from reporting systems. And once you make this separation the whole CQRS-aspect naturally falls out. It makes sense, for example, to keep all orders in something like Cassandra or VoltDB for reporting though you'd never do that for execution. The thing is, CQRS is not an end to itself. I'm not sure why it has blown up in the .NET world. Again, something has been lost here. The CQRS tactic is required only when reporting requirements and execution requirements are fundamentally different/incompatible. An EDA makes CQRS-style separation possible but it does not require it. And here's the thing: if you have your end-points designed correctly it's trivial to separate out querying if it's needed. Just model your system using events and aggregates and it should work out.
I wasn't even going to comment on this thread. Most of the comments here are your typical HN nonsense -- a potent mixture of ignorance and anti-innovation FUD. But your link to the writeup was enlightening (and horrifying) if only to reveal how people can go very wrong with this "new" architectural style. (Again, event-sourcing, and EDA in general, has been de rigeur in finance since the 80s.)