6 ms·

I read this, and this article has a lot of words that I don’t know, and that make me feel intimidated for having missed out on something important for the last

I read this, and this article has a lot of words that I don’t know, and that make me feel intimidated for having missed out on something important for the last ten years of my professional career. The first time someone told me about EDA was when I told them I had problems optimizing a certain SQL query, to which their answer was whether I have considered using event sourcing or storming.

dncornholio 4y ago
No reason to panic. As I see it, this person is just talking buzz.
mrkeen 4y ago
> missed out on something important for the last ten years * If you write down what happened ("events"), and don't throw away said events, then you can always compare the current state of the system to how you think it should be (according to the events). > I had problems optimizing a certain SQL query * If you don't mutate your events, you are allowed to share them. Perhaps the DB you were working with had an unsuitable structure, making it hard to write fast SQL. No worries! Create a second service/DB with a structure designed for fast querying. Slurp the events which you did not throw away into your new database, and enjoy fast queries (without needing to break or cause regressions in the first service/db).
- throwaway290 4y ago
  > you can always compare the current state of the system to how you think it should be Unless what happens in the system is different now and old events don't make sense anymore...
  - ElevenLathe 4y ago
    Versioning your events can help with this, along with a test suite that will complain if you change the semantics of events with older versions.
  - Joker_vD 4y ago
    Or the events do still make sense, it's just the processing rules for them have changed several times over the years and of course, the event "use the business rules ver. X.Y from now on" is not logged anywhere.
- bitcurious 4y ago
  > * If you write down what happened ("events"), and don't throw away said events, then you can always compare the current state of the system to how you think it should be (according to the events). This, by the way, is the fundamental principle of accounting. When you hear “reconciliation” this is what they’re doing - comparing some data reflecting real events against a log of intended events. For example, a nonprofit might reconcile their bank account (actual $ amounts) against GL files generated from their CRM (expected $ amounts.)

dncornholio 4y ago

No reason to panic. As I see it, this person is just talking buzz.

mrkeen 4y ago

> missed out on something important for the last ten years * If you write down what happened ("events"), and don't throw away said events, then you can always compare the current state of the system to how you think it should be (according to the events). > I had problems optimizing a certain SQL query * If you don't mutate your events, you are allowed to share them. Perhaps the DB you were working with had an unsuitable structure, making it hard to write fast SQL. No worries! Create a second service/DB with a structure designed for fast querying. Slurp the events which you did not throw away into your new database, and enjoy fast queries (without needing to break or cause regressions in the first service/db).

throwaway290 4y ago
> you can always compare the current state of the system to how you think it should be Unless what happens in the system is different now and old events don't make sense anymore...
- ElevenLathe 4y ago
  Versioning your events can help with this, along with a test suite that will complain if you change the semantics of events with older versions.
- Joker_vD 4y ago
  Or the events do still make sense, it's just the processing rules for them have changed several times over the years and of course, the event "use the business rules ver. X.Y from now on" is not logged anywhere.
bitcurious 4y ago
> * If you write down what happened ("events"), and don't throw away said events, then you can always compare the current state of the system to how you think it should be (according to the events). This, by the way, is the fundamental principle of accounting. When you hear “reconciliation” this is what they’re doing - comparing some data reflecting real events against a log of intended events. For example, a nonprofit might reconcile their bank account (actual $ amounts) against GL files generated from their CRM (expected $ amounts.)