DDD, event sourcing and CQRS - theory and practice

Рет қаралды 45,234

Күн бұрын

Numerous software projects fail not only because of the chosen technologies, but above all because of the lack of interdisciplinary communication. Developers and domain experts speak different languages and do not understand each other. In recent years, domain-driven design (DDD) has increasingly established itself as an approach to solving the problem. But how does DDD work and how does it relate to event sourcing and CQRS? The three concepts are often mentioned together, but are in fact independent of each other - but under certain circumstances they can complement each other very well. In the session you unravel the weave together with Golo Roden. He will also show you how to develop a cloud application with JavaScript based on DDD, event sourcing and CQRS.
Session by Golo Roden at iJS 2018
😊 Come, join us at the next International JavaScript Conference | javascript-conference.com/
👉 Follow us on Twitter | / javascriptcon
👍 Like us on Facebook | / javascriptcon

Пікірлер: 37

@cyniquemisanthrope4172 3 жыл бұрын

This is how tech talks should be done. Concise, clear and straight to the point!

@WaveMrNight 3 жыл бұрын

2 years after, this is still awesome

@girlsincode9255 3 жыл бұрын

best explanation for DDD, event-sourcing and CQRS.

@danielwarke4742 2 жыл бұрын

Thank you!! Spent hours looking for an easy to understand explanation of these concepts and this video is the best one by far

@muchfitter1124 3 жыл бұрын

THIS IS GOLD, GOLO! Thanks!

@ahmaddeveloper7595 3 жыл бұрын

incredible presentation, very intuitive and not convoluted with dry and hard-to-consume concepts

@VladimirRoytman 3 жыл бұрын

Very clear, understandable and straight-forward presentation. Thank you!

@maksimsergeevich5939 3 жыл бұрын

Wow! Nice that I found this video! I just introduced the Wolkenkit to myself yesterday!

@Jonathan-od5xc 4 жыл бұрын

This is exemplary, thank you very much

@hiimshort 3 жыл бұрын

Great talk with things distilled to an understandable level. Well done!

@JulesRulez65 Жыл бұрын

Du bist der Hammer, Golo!

@Jensemann099 4 жыл бұрын

This is a great talk!

@maour 5 жыл бұрын

Great talk, thanks

@kevinpeters3940 5 жыл бұрын

Lmaooo amazing talk, I love how the backend engineers clap for the animations and css 😂

@ehsanahmadi8976 3 жыл бұрын

Thank you it was so straightforward

@lotofhop5972 Жыл бұрын

That was so great hour, thanks a lot!

@rajsaraogi 4 жыл бұрын

@24:25 Event sourcing, not only storing the current state but also storing the chain of events which lead to current state.

@banatibor83 Жыл бұрын

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!

@AssFaceNFT Жыл бұрын

Very well explained! Thank you ser 🙏🌹

@lapseofeternity 3 жыл бұрын

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.

@therealmikz 3 жыл бұрын

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.

@LvvMontenegro 4 жыл бұрын

wish i could like it more than once

2 жыл бұрын

That was awesome!! thanks for sharing

@rajsaraogi 4 жыл бұрын

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