Great video. I'm just starting to learn how distributed systems work. After having worked many years with traditional systems (monolithic/ rdbms) it's fascinating to learn these new concepts.
Absolutely great talk I would like to add that Akka is a great way to implement a DDD model. Event sourcing comes out of the box when used with Akka persistence (which is just an addition to the actor model). I've tried using plain old Java with Spring, but the Scala/Akka combo is just great, because most things are available in the Actor library.
It is my opinion that it is always good to learn new things but in the case of creating applications that are modeled using DDD, Scala in combination with Akka makes it very easy to create highly scalable applications for the JVM. The concise syntax of Scala makes it very easy to implement applications that are modeled leveraging DDD and the Scala bias to immutability makes the application cloud scale ready, even if you don't need that at first.
by the way, on one of the slides, CQRS was shown as CQR separation, but it is segregation, not separation. there is yet another abbreviation CQS that stands for Command query separation. en.wikipedia.org/wiki/Command%E2%80%93query_separation#Command_query_responsibility_segregation
@Michael Plöd Fantastic Talk, thank you so much. Just a quick question regarding "Never change events". How do you handle compatibility with future versions? Let's say you are developing an application and you get it running, publishing events in version 1. Some time later you have further developed your application and you had to change those events. In order to be processed correctly in case of a "replay", the old events would have to adhere to the new event version. Any recommendations on this?
4 года назад
I think there's many ways to do that, but you could add a "version" attribute to your events. The aggregates will need to be able to deserialise correctly all versions of an event, though.
Fantastic explanation of CQRS/Event Sourcing Micheal!! A quick question though, isn't "S" of CQRS is "segregation" instead of "Separation" , though it might just be trivial.
Greg Young's CQRS documents use the word "segregation" but it also mentions that it "originated with Bertrand Meyer’s Command and Query *Separation* Principle" - neither of you are wrong of course :-)
Please learn the difference between “parallel” and “concurrent” its highly irritating. And no, that isn’t some nitpicking detail because those terms are different things which can and often do pop up in the same context
can we get the code sample or step by step code guide where new babies like me can understand more about this? this is one of the best video i have seen of this topic. i am still sightly confuse about CQRS that how read and write will happen. but i guess if i can get sample code it will be more helpful.
for eventsourcing nice and sort example you can find github.com/RisingStack/event-sourcing-example it is in nodejs but the concept is really sort and simple
i think every domain is unique and one should choose architecture based on one's own analysis.However just as an opinion poll - do you guys think this approach is good for Supply Chain Systems.
Hello Anug14, yes its good since we have several actors within the supply chain and the events happens in a sequential manner. You can think of reversals which entails transactions compensation
ok... lets say we are using in memory data base for data store ... when ever the application is down ...we need to rebuild everything using event source from the beginning ... what if it happens after 2 years ?
Loading millions or billions of events can take from a few minutes up to a couple of hours. If you have multiple replicas of each in-memory readmodel you can perform a rolling upgrade without downtime.
How do you save different states of the read-model if you have it (only) in memory? I am wondering how you would save old events combined, so you could start with that and only apply new events.
This is called snapshots. You would typically write code that dumps the in-memory model to persistent storage and read it back again when the system starts up. This is not necessarily faster than just replaying all the events, depending on the size and complexity of the projection and th number of events.
"Never delete/modify events" is basically not possible due to GDPR. You are legally forced to remove or anonymize user data if the user requests it or cancels your service
One thing that was pointed out in another talk about CQRS and GDPR. When creating a new object have an event that generates an encryption key and add to the event queue. All user data can be encrypted using the encryption key and events are saved that way. The only thing that has to be modified if the user asks to be removed is to remove the save of the encryption key event. Now the data is encrypted and cannot be recovered but the events are not changed. This adds some overhead but if you are judicious with using data objects to save the personal data so encryption can happen on a block of data instead of fields at a time.
don't you think "CustomerVerifiedEvent" should be named as "CustomerVerificationEvent" because you don't know the outcome of the event, the customer passed verification or failed verification??? But "CustomerVerifiedEvent" always indicates passed logically...what about if verification failed?
If you need a special logic for when the customer failed the verification, you would have to create an event "CustomerFailedVerificationEvent", basically you create the events you need for the business logic but the events must always indicate what happened.
In the case of validation mentioned in 54:20, how the 2 users with same email address get entered in the system? Are you not validating? I didn't get that point, can any one help me
He explained it pretty straight and answer is you validate against read model which might not be up to date and you have inconsistent event store state now... and author says that it is not a big deal... it is a huge deal, I understand cool aspects of event sourcing but this fundamental eventual consistency is just a huge inconvenience. It is not only user registration there might be tens of examples where I want to validate current state of the system before commit next event and every time I should email a manager or make a discarding event?
@Stan Agreed and for the duplicate email address example used it would be very hard to explain to someone non-technical how it had occurred whilst maintaining a serious face. It also opens opportunities for malicious exploitation of inconsistent state. It does feel like going back to go forward.
CQRS as it stands today has very little value unless the business can live with its fundamental limitation of eventual consistency. Instead of accepting this limitation, proponents of CQRS turn the tables and say Strong consistency is bad. There is no sane way to get around eventual aspect. Commands are forced to go to event handler to get processed as and there is no sane way to achieve consistency without compromising latency How many businesses want their customer to signup again later because the event handler was busy handling other events. Sure, we can throw a lot of resources to achieve consistency, but is it really worth it? Sharding is a reasonable alternative if load on single strong consistent store does not scale well. May be distributed SQL stores like cockroach db might help if used smartly The only value you have is event sourcing which allows us to have business events & the ability to replay
Author's statement on this issue made me also uncomfortable because it is not such a process as simple as he defined when you look from the view of user perspective. I think (at least this is what I understood) what he wanted to mention was focus on your domain subject and if what you interested in that manner is out of the main domain then don't give too much care on it. In this particular case, if your main objective is not registering user (along the whole application) then skip this parts with simple actions???
