I gained a lot of understanding from this. Would be interesting to see how this demo would change if written as a distributed system broken into microservices with a message broker (RabbitMQ, Kafka, Azure Service Bus) thrown in the mix... Thanks for the great talk! Keep up the good work!
An awesome way to show code, which I recently found, is to use code snippets. So in your sample project, just have a comment where you want to show the code. The comment can be something like the "snippet code" and a number, to keep track of your snippets for the presentation.
I love Surface Books and the Surface Laptop as well, the accent is not that bad mate :D I got everything u said and english is not my native language :)
Yes, I cannot understand why not using Rider. As he said: "license expires today", he is giving strange excuses. ok, so why not get personal license for $14 and continue using Rider (www.jetbrains.com/rider/buy/#personal?billing=monthly)
I have a lot of problems with this talk. First, if you are going to speak about something, at least make sure you know what the acronym means! It´s not too much to ask, and makes me wonder, does this guy really knows his stuff? Second, and this is more general: WHY EVERY SPEAKER MAKES AN EFFORT TO MAKE HIS CODE LOOK LIKE IT WAS WRITTEN UNDER THE EFFECTS OF LSD?, seriously, it´s like an ego thing, the less you understand my code, the better it is (when we all know it´s the exact opposite). IMHO that code was a total mess and completely unintelligible. This is not something personal with the speaker (he really knows a lot) but with the majority of speakers in conferences, just don´t make your code full of stuff and magic so that only you can understand it and we all look at it trying to figure out what the heck it does!!
Thanks for the feedback, sorry about forgetting the acronym, but giving a talk is a bit stressful and these obvious things sometimes slip your mind. As for the code demo I worked as hard as I could to deliver something that was both understandable but also real world. Tricky to do sometimes I admit. Anyway the source is here github.com/mat-mcloughlin/PatientMangement. If you want to chat about it more I'm happy to do so.
Thanks for the reply! Please don´t take my comment as classic youtube trolling, it was just constructive criticism based on MY opinion (not facts), because I really liked the talk. As for the code, I think that in some parts it could have been made a little easier to understand, just that. I'm worried that you think I said the code was crap, absolutely not. Again, thanks for the reply (and for the code)!!
(I appreciate this is a year on from the comment, and 3 years from the upload to the git repo, however) Conversely, I appreciate some fairly realistic code being shown that wasn't 100% unusable demo code. It seems concise and easy to follow tbh. If you have a problem with a particular part of the presentation, I'd suggest outlining what was troublesome, why, then how you'd like to see it presented instead. If you really want to go the extra mile, it's a git repo, so put in a pull request :) This is a complex, advanced topic area, so it's not unreasonable to expect fairly complex code.
9 minutes and I'm not confident. 1. Why does the Admit event have patient information AND an id? Isn't a patient registered first? And then admitted? 2. Did this guy ever hear about normalisation? No one should be storing patient data like that. So many people make event sourcing sound so magical when it's simply ensuring you can regenerate your state by replaying an event log! The thing is, there's no reason to force eventual consistency using this model like so many practitioners do. You could update your *primary* read model and store the events in the same transaction. After all, we all start an application knowing the the shape of data we need to have. Storing the events just allows us to still benefit from future use cases as well as rebuilding our data. In fact, you can do a data migration easily with this. But I really don't get all the ceremony and complication around doing this.
Expanding on my previous ideas, you could then go on to build a system around your events that allows you to connect random handlers to build additional projections. The way it's sold, ES mainly yields future benefits right? Benefits of the analytical nature mostly. If your primary model needs to change, that means your application is going to change. There's really no need to for this to be eventually consistent.
Normalization can be a double-edged sword. In my business, our data is TOO normalized and makes certain queries very slow due to how much joining needs to happen.
1. Because the id is a guid generated by the app instead of an auto incrementing int generated by the db. In a distributed architecture you can't really rely on auto incremented ids from a db when you use multiple dbs for different data. 2. Data normalisation came about when storage space was very limited and expensive. These days storage is cheap and denormalization comes with a good bit of performance increases.
@@someguyO2W came late for the discussion, but as i Know, with CQRS you have 2 databases, one normalized to store data and make analytics and another denormalized with a document database that hold on the data has the view required it and also that will store the events message so you can just replay the events and see what happened any time in the past
![Run Away - Tzuyu(TWICE) ツウィ 쯔위 [Music Bank] | KBS WORLD TV 240906](http://i.ytimg.com/vi/KnHNNyAYiu0/mqdefault.jpg)
Thanks. Great talk and nice clear working example. Clarified some of the concepts I had been wondering about.
I gained a lot of understanding from this. Would be interesting to see how this demo would change if written as a distributed system broken into microservices with a message broker (RabbitMQ, Kafka, Azure Service Bus) thrown in the mix... Thanks for the great talk! Keep up the good work!
What a lovely accent!
Tony Ferguson is the type of guy to mutate your immutable event log.
Why NDC don't upload demo app ???
An awesome way to show code, which I recently found, is to use code snippets. So in your sample project, just have a comment where you want to show the code. The comment can be something like the "snippet code" and a number, to keep track of your snippets for the presentation.
Thanks, this video and source code on github helped me a lot.
I love Surface Books and the Surface Laptop as well, the accent is not that bad mate :D I got everything u said and english is not my native language :)
Thanks 🙏
The water bottle is bottomless.... great video anyways...
Seriously it was really bloody warm in that room
Tony Ferguson is the man though.
where is demo code
Demo starts at 26:00
You said have you tried "writer' whats writer at around 33:40 and said your copy expired? Just wondering
Rider. It's a .NET IDE from JetBrains.
Yes, I cannot understand why not using Rider.
As he said: "license expires today", he is giving strange excuses.
ok, so why not get personal license for $14 and continue using Rider (www.jetbrains.com/rider/buy/#personal?billing=monthly)
Can someone please recommend books to learn this? I found a lot but reviews are bad.
www.amazon.com/-/es/Hands-Domain-Driven-Design-NET-ebook/dp/B07C5WSR9B/ref=mp_s_a_1_6?dchild=1&keywords=Ddd+book&qid=1599351815&sr=8-6
thirsty fellow eh ...
I have a lot of problems with this talk. First, if you are going to speak about something, at least make sure you know what the acronym means! It´s not too much to ask, and makes me wonder, does this guy really knows his stuff?
Second, and this is more general: WHY EVERY SPEAKER MAKES AN EFFORT TO MAKE HIS CODE LOOK LIKE IT WAS WRITTEN UNDER THE EFFECTS OF LSD?, seriously, it´s like an ego thing, the less you understand my code, the better it is (when we all know it´s the exact opposite). IMHO that code was a total mess and completely unintelligible.
This is not something personal with the speaker (he really knows a lot) but with the majority of speakers in conferences, just don´t make your code full of stuff and magic so that only you can understand it and we all look at it trying to figure out what the heck it does!!
Thanks for the feedback, sorry about forgetting the acronym, but giving a talk is a bit stressful and these obvious things sometimes slip your mind.
As for the code demo I worked as hard as I could to deliver something that was both understandable but also real world. Tricky to do sometimes I admit. Anyway the source is here github.com/mat-mcloughlin/PatientMangement. If you want to chat about it more I'm happy to do so.
Thanks for the reply! Please don´t take my comment as classic youtube trolling, it was just constructive criticism based on MY opinion (not facts), because I really liked the talk.
As for the code, I think that in some parts it could have been made a little easier to understand, just that.
I'm worried that you think I said the code was crap, absolutely not.
Again, thanks for the reply (and for the code)!!
:+1:
(I appreciate this is a year on from the comment, and 3 years from the upload to the git repo, however) Conversely, I appreciate some fairly realistic code being shown that wasn't 100% unusable demo code. It seems concise and easy to follow tbh. If you have a problem with a particular part of the presentation, I'd suggest outlining what was troublesome, why, then how you'd like to see it presented instead. If you really want to go the extra mile, it's a git repo, so put in a pull request :) This is a complex, advanced topic area, so it's not unreasonable to expect fairly complex code.
9 minutes and I'm not confident.
1. Why does the Admit event have patient information AND an id? Isn't a patient registered first? And then admitted?
2. Did this guy ever hear about normalisation? No one should be storing patient data like that.
So many people make event sourcing sound so magical when it's simply ensuring you can regenerate your state by replaying an event log!
The thing is, there's no reason to force eventual consistency using this model like so many practitioners do.
You could update your *primary* read model and store the events in the same transaction. After all, we all start an application knowing the the shape of data we need to have.
Storing the events just allows us to still benefit from future use cases as well as rebuilding our data. In fact, you can do a data migration easily with this.
But I really don't get all the ceremony and complication around doing this.
Expanding on my previous ideas, you could then go on to build a system around your events that allows you to connect random handlers to build additional projections.
The way it's sold, ES mainly yields future benefits right? Benefits of the analytical nature mostly. If your primary model needs to change, that means your application is going to change.
There's really no need to for this to be eventually consistent.
Normalization can be a double-edged sword. In my business, our data is TOO normalized and makes certain queries very slow due to how much joining needs to happen.
1. Because the id is a guid generated by the app instead of an auto incrementing int generated by the db. In a distributed architecture you can't really rely on auto incremented ids from a db when you use multiple dbs for different data.
2. Data normalisation came about when storage space was very limited and expensive. These days storage is cheap and denormalization comes with a good bit of performance increases.
@@someguyO2W came late for the discussion, but as i Know, with CQRS you have 2 databases, one normalized to store data and make analytics and another denormalized with a document database that hold on the data has the view required it and also that will store the events message so you can just replay the events and see what happened any time in the past
@@___-ls9ly for distributed auto generated ids see how Netflix does it.