19
I sketched my rough understanding on how an ES / CQRS app should look like contextualized to a simplified banking use case (withdrawing money).
This is the perfect example of an event sourced application. Let's start.
Every time a command is processed or retried (you will understand, be patient) the following steps are performed:
the command reaches a ...
18
Since you tagged your question with "CQRS", I guess you mean events in a "CQRS & Event Sourcing" context, like it is described here. In this tutorial, the difference between events and commands is well explained:
events capture the elementary "things that can happen" in your system, from the system's point of view.
commands are defined by what the user ...
17
Disclaimler: I'm only taking my first steps in the CQRS world, but I can offer my current understanding of the matter and we'll see if others confirm. All I write below has an underlying "as I see it" theme, and is not authoritative.
The 80% case
To answer your question, commands are indeed a point-to-point affair. When a command enters a controller (MVC ...
16
First, it is important to understand and be able to leverage the difference between Commands and Events.
As this question succinctly points out, Commands are things we would like to happen, and Events are things that have already happened. A command does not necessarily result in a significant event in the system, but it usually does. For example, a send ...
13
The idea in Udi's post, as I gather, is that no kind of item appears out of thin air. There is (almost) always something, or more specifically, some domain operation, which caused the item to be created. Just like Udi's example of a user actually being born out of a visitor registering to the site. At that point and at that bounded context Visitor is the ...
13
Review what Rinat Abdullin wrote about evolving business process. In particular, notice his recommendation for developing a business process in a fast changing environment -- a process manager is "just" an automated replacement for a human being staring at a screen.
My own mental model of a process manager is that it is an event sourced projection that you ...
13
proto3 makes a number of changes aimed (as I understand it) at making it far more usable in cross-platform scenarios. Explicit tracking of "assigned" vs "not assigned but reporting the default value" can be very hard to implement on some of the target platforms, and can also be confusing to use. As such, proto3 adopts a much simpler approach:
the implicit ...
13
What I'm not super clear on is why you would ever rehydrate your Aggregates from the Event Store itself.
Because the "events" are the book of record.
If projecting changes to "read" databases is so easy, why not always project changes to a "write" database whose schema perfectly matches your domain model? This would effectively be a snapshot database.
...
12
CQRS and DDD are separate/orthogonal concepts, and I think you divided the terms pretty close to right.
Events under DDD are called Domain Events, and are somewhat different from the Messaging events often mentioned with CQRS. Messaging events usually have more to do with Event Sourcing.
Your CQRS category is a conglomeration of a number of patterns, and ...
12
How do I deal with side effects in Event Sourcing?
Short version: the domain model doesn't perform side effects. It tracks them. Side effects are performed using a port that connects to the boundary; when the email is sent, you send the acknowledgement back to the domain model.
This means that the email is sent outside of the transaction that updates the
...
12
The term Event driven architecture is used for any kind of software system which is based on components communicating mainly or exclusively through events. For example, almost any major GUI framework on any popular platform uses event-driven mechanics. The term "event" usually means "notification" in this context.
Event sourcing is a much more special term, ...
11
I think you may have a user-process to implementation mismatch here.
First: will a user honestly want to perform multiple changes to a file simultaneously?
A rename (which may or may not include a change of path?), change of ownership, and perhaps change of file contents (for sake of argument) seem like separate actions.
Lets take the case where the answer ...
11
In retrospect, I think I was complicating the issue.
In general, commands should either throw an exception or raise one or more events.
If I could summarise the architecture of Event Sourcing it would be as follows:
Commands are inputs representing instructions to do something.
Events are outputs representing historical facts of what was done.
Event ...
11
My guess is that you need to explore more carefully an approach that you have rejected
Enqueue the events on our server
My suggestion would be to start reading through the various articles published about the LMAX architecture. They managed to make high volume batching work for their use case, and it may be possible to make your trade offs look more like ...
10
I may be able to provide a bit of (biased) insight (that you shouldn't take at face value) since I recently had the pleasure to do a proof of concept in implementing eventsourcing for one of my companies products. Before this POC we had a "classic" system with a RDBMS in the bottom that did not save any events, the proof of concept was to replace the entire ...
10
Well they are three separate things and they are real things not just buzz words. But....
Domain Driven Design. I've seen this used quiet commonly now, at least in a 'lite' fashion. I think it does help to define and break down a system into component parts.
Command Query Segregation. Although there are cases where you want to have a read only db and a ...
9
The concepts behind Event Sourcing have been around a long time, and often with other names. Tandem computers were built on this idea as was IBMs IMS TM. IMS TM was developed for the Apollo space program in the 60s and Tandem appeared in the 70s.
Many modern high-performance systems for the financial domain are built on such patterns. Almost all are ...
9
Not sure that there is a 'one true way' answer for a design approach that, to be fair, is still evolving. First, DDD and CQRS are not the same thing although the CQRS folks seem to have derived from a DDD-influenced starting point.
There's a lot going on in the DDD mindset and much of it has to do with properly defined boundaries of problems, communication ...
9
IMHO there's no such thing as really changing an event - if that happens you've really created a new event type. Once an event has happened in production, it's happened.
The cleanest way to handle this is to version your events and have an 'event upgrader' somewhere in your pipeline before the events get applied - we do it just after the events are ...
9
With Event Sourcing the main question is "what is your book of record".
If your book of record is your event stream then you will have no problems. If your book of record is your "entity model" then problems will start happening all over the place. Part of this is that you can say "if I lost my entity model could I rebuild it from my event stream". If you ...
9
Usually one command will lead to one event. But in some cases it can also be more than one, it depends on your implementation.
Either your command calls other commands and each of them fire own events. Or your command does different tasks on it's own and issues multiple events. For example:
RegisterUserCommand
User.create(email, password) → ...
9
One command can raise multiple events. It is simply logical conclusion of one fact : Composite command exists.
Lets say you have two commands, each raising an event. Then, you create a composite command of those two. From the view of one using the composite command, it seems as if the command raised two events.
So there is nothing stopping you from having ...
9
Input stream
It is not clear if your 1000 events/second represent peaks or if it's a continuous load:
if it's a peak, you could use a message queue as buffer to spread the load on the DB server over a longer time;
if it's constant load, the message queue alone is not sufficient, because the DB server will never be able to catch up. Then you'd need to ...
8
You will benefit the most from the event sourcing when you decide to change your system architecture also. Going towards a CQRS style architecture combined with DDD will bring up the true benefits of an event sourcing, at least in my opinion.
Building an event store that behaves well in large systems is not an easy task indeed. Replaying all the data might ...
8
You shouldn't delete the events from your event store. These represent something that happened.
If something happens now, then you should know it too, therefore add an event that will force your aggregate to go back to some previous state. That's a pity to delete information from your database.
think about the example of the cart from greg young and the ...
7
You could use an index. This is generally not something that you will find in an eventstore, so you will most likely need to use an external indexing engine for this.
This index would then have to be updated everytime that someone changes a carts contents, and this index update would most likely be async. This would mean that you cannot rely on your index ...
7
With the CQRS/ES in mind, I have a decision engine. The decision engine for producing an event from a command, is the Business Domain, which has to be purely functional.
Good.
When a command asks for an Item to be created, the decision engine chooses to accept or not to create an event CreateItem only if the Item is not already existing (simplified for ...
7
When transferring it's different - two aggregates must be modified by one MoneyTransferred event.
Transferring money is a separate act from updating the ledgers.
MoneyTransferred
AccountCredited
AccountDebited
The exercise that finally broke this loose for me was realizing that AccountOverdrawn is an event, it describes the state of the account without ...
7
Event Sourcing is hard and doesn't achieve a great deal on its own.
Also, People confuse Event Sourcing with a whole tonne of other things and find that they haven't achieved what they expected at the end of the project.
Having said that, I bet you can find articles on the internet saying anything is an anti-pattern with very little effort. These ideas ...
6
If you only want to be able to understand what happened in your application (i.e. what the state of your application was at a specific point in time and, potentially, who initiated a state change), an Audit Log may well be all you need. An Audit Log does not make any assumptions as to how you store the currently valid state of your application, i.e. it is ...
Only top voted, non community-wiki answers of a minimum length are eligible
