22 thoughts on “GOTO 2017 • The Many Meanings of Event-Driven Architecture • Martin Fowler”

  • 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.

  • 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.

  • הוنᄀバコᄂᄃɸฅจـهـ母表จาøนحöܠʢܢחق한국어י says:

    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.

  • blahdelablah says:

    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.

  • Andreas Melcher says:

    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 detected
    People normally call their system "event-driven" if at least one of those patterns is in place

    03:20 Pattern 1: Event Notification
    Generic code notifies specific code by events
    for example GUI elements

    08:33 Events vs Commands
    Events just indicate a change without expecting any particular response
    Commands 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 Transfer
    Subscribers 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 data
    Contra: consistency
    It's Less used

    20:51 Pattern 3: Event Sourcing
    Ability to rebuild the full state of the system by a persisted log of events
    Event Sourcing works with your data like version control systems work with your code
    Pro: "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: CQRS
    Separate components for updating the system and reading from the system
    Different 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 patterns
    When 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.

  • Another Elvis says:

    According to 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.

  • Victor Sujingo says:

    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?

  • HariLilNandan says:

    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.

  • Michael Reardon says:

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *