It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Think about states. A traditionally designed database represents the last known state of a system: Jane was admitted to hospital on this day, for these reasons, is staying in room 119, was seen by doctor so-and-so at 11am.
Certain states are consistent: for example, one visit with a doctor is much like another visit with a doctor. In a traditional database, you'd represent this with a junction table relating this doctor to that patient at this time. Retrieving junction and related records gives you a timeline of visits. What it doesn't give you is context: all you know from querying the visits table is that Jane was (presumably) in the hospital some time before her first visit and some time after her last. Admittance and discharge are external; prescription updates are external; all kinds of things that would be very useful to know about in the context of visit history are somewhere else, and difficult or impossible to aggregate.
Besides Jane herself, there's one important aspect of each data point I mentioned: it happened at a certain time. Jane was admitted; Jane saw a doctor; Jane was allocated a room; Jane received a new prescription; Jane saw another or the same doctor; Jane was discharged. Event sourcing correlates the identifier (here, the number printed on Jane's wristband) with the time something happened. Each thing that happened during Jane's stay is an event: there's an admittance event, a visit event, a room allocation event, a prescription event, another visit event, a discharge event.
Each event includes some relevant information, with a visit being tied to the doctor, the prescription to the medication info, and so on. As an event is processed, that information may be materialized into tables which reflect the current state (eg a rooms table which now shows that #119 is occupied). But the events table is the source of truth, and the state tables can be completely deleted and reconstituted simply by processing all the events in order again. That's the "sourcing" part. Also, it can be useful to simply query all events relating to Jane to get a complete history of her stay in one place.
Think about states. A traditionally designed database represents the last known state of a system: Jane was admitted to hospital on this day, for these reasons, is staying in room 119, was seen by doctor so-and-so at 11am.
Certain states are consistent: for example, one visit with a doctor is much like another visit with a doctor. In a traditional database, you'd represent this with a junction table relating this doctor to that patient at this time. Retrieving junction and related records gives you a timeline of visits. What it doesn't give you is context: all you know from querying the visits table is that Jane was (presumably) in the hospital some time before her first visit and some time after her last. Admittance and discharge are external; prescription updates are external; all kinds of things that would be very useful to know about in the context of visit history are somewhere else, and difficult or impossible to aggregate.
Besides Jane herself, there's one important aspect of each data point I mentioned: it happened at a certain time. Jane was admitted; Jane saw a doctor; Jane was allocated a room; Jane received a new prescription; Jane saw another or the same doctor; Jane was discharged. Event sourcing correlates the identifier (here, the number printed on Jane's wristband) with the time something happened. Each thing that happened during Jane's stay is an event: there's an admittance event, a visit event, a room allocation event, a prescription event, another visit event, a discharge event.
Each event includes some relevant information, with a visit being tied to the doctor, the prescription to the medication info, and so on. As an event is processed, that information may be materialized into tables which reflect the current state (eg a
roomstable which now shows that #119 is occupied). But theeventstable is the source of truth, and the state tables can be completely deleted and reconstituted simply by processing all the events in order again. That's the "sourcing" part. Also, it can be useful to simply query all events relating to Jane to get a complete history of her stay in one place.Example may or may not have been shamelessly stolen from Mat McLoughlin's talk at NDC Oslo 2017 :)
Thanks a lot for the answer and the link.
Recently, I've found good video regarding this topic and Doman Driven Development in Ruby RubyC-2018 / Andrzej Krzywda "From Post.create to PostPublished.new"