Importance of Advertising
7:30 "First class thingimijig" is definitely a good name, but a name that already exists for this, which completely captures the semantics, is "data structure". We've turned a function call with transient arguments into a data structure in its own right.
9:00 if we phrase our data structure in the command form (the event content says "requote the customer"), then we have reintroduced the dependency, since the customer system must now know that the quoting system exists in order to be able to send that command. The decoupling only exists if using the pure event system. So this is not just a naming issue (although it is also that). If the reason for the event architecture is to invert the dependency, then commands simply cannot be used.
He sounds amazingly like bill bailey
this guy is so full of shit, almost everything he invented is stuff that I hate with a passion
Gosh he is a very good writer and just an okay talker.
Architecture astronauts love Event Sourcing, buyer beware!
I would strongly disagree that events and commands are the same and only differ in their names. Think of Laws, there you have incidents and consequences. Often it is the same in IT systems: the subsystem indicating a situation (event, change, whatever) can not know what the readers of the indication will do or have to do then. The cause can not know the effect, at least not in advance.
I wish could attend this conference
….and business process modeling….
….uh….topics and queues?
I played back 6:16 more than once 😛
The meanings of many words will continue to change, creating mass confusion along the way and self-proclaimed 'experts' telling everyone what things mean until such time when it's time to re-define them yet again.
He is great! Thank you for uploading!
why couldn't he use REST interface rather than event queue?
It strikes me that, in terms of the first example of an event-driven architecture, it'd be possible to get around the highlighted weakness with the notion of child events. If an event triggers other events to occur, then the subsequent events could be described as child events (and conversely, if an event was not driven by another event, it's a parent event). This could all be captured in the same event stream (parent events, child creation events and child completion events), so that you could have a fuller picture of what happened as a result of a single action in a software system.
could listen to the guy all day
Timed index of the video
0:00 What people mean by EDA
00:51 How he came to write down common patterns of EDA and hold this talk
02:45 4 patterns detectedPeople normally call their system "event-driven" if at least one of those patterns is in place
03:20 Pattern 1: Event NotificationGeneric code notifies specific code by eventsfor example GUI elements
08:33 Events vs CommandsEvents just indicate a change without expecting any particular responseCommands are telling some service what to do
11:30 Pro: Decoupling
13:50 Contra: inability to understand what is going on by stepping through the code
14:53 Pattern 2: Event-carried State TransferSubscribers don't ask for additional information after an event occured, all necessary state is given in the events. Subscribers copy whatever they need.Pro: can greatly reduce network traffic. Better availability because of the copied dataContra: consistencyIt's Less used
20:51 Pattern 3: Event SourcingAbility to rebuild the full state of the system by a persisted log of eventsEvent Sourcing works with your data like version control systems work with your codePro: "time traveling" like for debugging. use a copy of the system, feed it the events and see what happened
32:11 Can be a very nice system development-wise
33:43 Downside of Event Sourcing– unfamiliar– when I rebuild the state from the log I can't replay answers of external systems unless I record all answers as kind of events– old event schema still has to work somehow with new versions of code– IDs that are generated during replay are probably different than before– Asynchrony is difficult for people (but it's optional. You can synchronously use event sourcing)– Versioning (Snapshots can make that easier)
(Conclusion for me: Always remember that replay has to work for everything, otherwise there is no point in using event sourcing)
38:46 Which events to record in the event store?Two events happen for a state change. One shows the intention (command), the other shows all the different changes that were done.Events that show intention often hold specific knowledge, the EventStore normally should stay generic (git only knows txt, not the used programming language syntax)It's important to think about which of those events are important to persist. Probably both.
43:31 Pattern 4: CQRSSeparate components for updating the system and reading from the systemDifferent views of the data are pretty common (e.g. a reporting database), the important thing here is that the command model is never used for reading from outside
47:39 Conclusion : How to use the knowledge about those 4 patternsWhen you hear about a system being "event-driven" ask questions to find out what patterns they use. Because the term "event-driven" is too imprecise.Have enough knowledge about each pattern to know where the problems are and what consequences they cause.
According to cqrs.nu/faq. An event represents a statement of fact, so it cannot fail, but a command is a request to make a perform a change, so it may be refused.
remember brought some of his books on topics like design pattern and refactoring when i learnt how to program … more than 10 years ago i guess
Great talk! Learned quite a lot. I think CQRS needs a bit more explaining compared to the reporting database. My understanding was the data source of the read side of the UI will be served via a different view than the one built entirely for the reporting purposes? Because, reports are targeted for different audience who needs it for analysis, export and other purposes..But the read part of CQRS needs to serve the same screen where the user is interacting with the application.. so I think there is a subtle difference?
Hmm.. this Event carried state transfer or whatever was implemented almost a year ago at our end. You can define the criteria at your model itself which is then checked against the state during RESTful CRUD operation. So the event can be defined for Cr, U or D even apart from just U as in the example here. Of course the attributes can also be defined, so that a copy of it (such as customer's address) is sent along with the event trigger instead of a copy of the entire instance.
anyone has adopted this approach in iOS ?
This is a great talk, and has led me to some helpful incites. Like most commenters though, I'm only going to point out what I don't like. I’m having trouble digesting the notion that Command messages are going to make reasoning about the system any easier than Event Notification. I think that has more to do with asynchronous operations than with the names and expected behavior of messages.
Your email address will not be published. Required fields are marked *
Save my name, email, and website in this browser for the next time I comment.