For those who haven't read the book and watch this video. First, read the book Domain-driven Design by Eric Evans. The language is ubiquitous, it is a property of the language of the domain or the bounded context. It means it permeates everything, discussions, documents, diagrams, and the code itself!
In my experience, adding the current state of the aggregate along with the event makes the events idempotent for subscribers because rather than projecting the event on local state, the subscribers can trust the state generated when the event was triggered. Then, the events in the message payload can be used to trigger actions. So even if events arrive out of order, the read state still remains consistent. e.g. user_created and user_activated are 2 events generated when new user joins. A notifier should send an email when user_created event arrives. Without current state, ordering must be maintained as the user instance won’t even exist if user_activated arrives first. Also, user_activated may just have user id and not the info because that may be only in user_created (since users can activate / deactivate at anytime). So if you include the state, the user_activated message can still be processed by notifier to update its local store with user’s email and when user_created arrives, it can discard the state from that message (lesser sequence number) and just trigger the action based on the event. So state controlled by message.state and actions controlled by message.event.
Adding the "current state of the aggregate" doesn't seem to me as a good solution to anything. Basically if your aggregate is event sourced, you often cannot define any structure as a state because every module/microservice can contain different structure and treat it as its view of the aggregate, it means not only that you'd have compatibility issues but also you're leaking domain data all over your system. Also there's overhead of creating serialization/deserialization logic, it becomes harder to change aggregate structure and it adds more data to your messages. But there's more: if you base your application on the CQRS, your aggregate can be HUGE. And those are just things of the top of my mind, I bet there's more to that. You might be interested in tracking correlation and causation identifiers of the events. Also take a look at the Saga pattern.
47:30 yes this is why collecting all possible data at every instance make event sourcing crucial, as we can't guess what kind of questions can arise later in our business
![[Smart4] [M.Chemel] Архитектура CQRS на примере NestJS](http://i.ytimg.com/vi/Zb6NMh6aeHo/mqdefault.jpg)
![[UNCUT] “บอสณวัฒน์” ลากไส้!! ใครหนุนหลัง "แม่ตั๊ก ป๋าเบียร์" I คนดังนั่งเคลียร์ I 30 ก.ย. 67](http://i.ytimg.com/vi/QlD7mU2KKRk/mqdefault.jpg)
This is how tech talks should be done. Concise, clear and straight to the point!
2 years after, this is still awesome
best explanation for DDD, event-sourcing and CQRS.
Thank you!! Spent hours looking for an easy to understand explanation of these concepts and this video is the best one by far
incredible presentation, very intuitive and not convoluted with dry and hard-to-consume concepts
Very clear, understandable and straight-forward presentation. Thank you!
THIS IS GOLD, GOLO! Thanks!
Wow! Nice that I found this video! I just introduced the Wolkenkit to myself yesterday!
This is exemplary, thank you very much
Lmaooo amazing talk, I love how the backend engineers clap for the animations and css 😂
Great talk with things distilled to an understandable level. Well done!
For those who haven't read the book and watch this video. First, read the book Domain-driven Design by Eric Evans.
The language is ubiquitous, it is a property of the language of the domain or the bounded context. It means it permeates everything, discussions, documents, diagrams, and the code itself!
In my experience, adding the current state of the aggregate along with the event makes the events idempotent for subscribers because rather than projecting the event on local state, the subscribers can trust the state generated when the event was triggered. Then, the events in the message payload can be used to trigger actions. So even if events arrive out of order, the read state still remains consistent. e.g. user_created and user_activated are 2 events generated when new user joins. A notifier should send an email when user_created event arrives. Without current state, ordering must be maintained as the user instance won’t even exist if user_activated arrives first. Also, user_activated may just have user id and not the info because that may be only in user_created (since users can activate / deactivate at anytime). So if you include the state, the user_activated message can still be processed by notifier to update its local store with user’s email and when user_created arrives, it can discard the state from that message (lesser sequence number) and just trigger the action based on the event. So state controlled by message.state and actions controlled by message.event.
Adding the "current state of the aggregate" doesn't seem to me as a good solution to anything. Basically if your aggregate is event sourced, you often cannot define any structure as a state because every module/microservice can contain different structure and treat it as its view of the aggregate, it means not only that you'd have compatibility issues but also you're leaking domain data all over your system. Also there's overhead of creating serialization/deserialization logic, it becomes harder to change aggregate structure and it adds more data to your messages. But there's more: if you base your application on the CQRS, your aggregate can be HUGE. And those are just things of the top of my mind, I bet there's more to that.
You might be interested in tracking correlation and causation identifiers of the events. Also take a look at the Saga pattern.
Du bist der Hammer, Golo!
@24:25 Event sourcing, not only storing the current state but also storing the chain of events which lead to current state.
Thank you it was so straightforward
47:30 yes this is why collecting all possible data at every instance make event sourcing crucial, as we can't guess what kind of questions can arise later in our business
wish i could like it more than once
This is a great talk!
That was so great hour, thanks a lot!
That was awesome!! thanks for sharing
Great talk, thanks
Thank you 🙏
What a teacherrrrrrrr💚
thanks a lot !
@17:10 commands are actions and events are system reaction.
Thank you!
26:18 great example that event is never deleted by using false transaction, the money is taken and refunded back but the log is never deleted
@19:50 things which have a state and access commands and fire events is called aggregate
I want to understand the magic behind Wolkenkit how can I Implement this from scratch, is there any suggestions that might help with that?
56:45 projections are which make the interpretation
Near the end, I really thought he will have a heart attack
Realy great! Thanks!
DDD, event sourcing and CQRS explained really well starting at th-cam.com/video/rolfJR9ERxo/w-d-xo.html
43:50 CAP theorem
Very well explained! Thank you ser 🙏🌹