Fork me on GitHub

@val_waeselynck Just finished the article, definitely echoes my own thoughts about Datomic. One of my favorite aspects of working with it is just how little you need to know about your domain model to make incremental progress. I am curious about the way you described transaction handling in traditional ES. I haven't built a system like that myself, but from the literature my sense of best practice is to do CQRS+ES, meaning you'd have some sort of command processor protecting the internal consistency constraints of each aggregate. Is that what you were getting at?


@val_waeselynck I would argue a little: datomic stores current state snapshots, I would not call it trully event sourcing event sourcing stores events that lead to current state so it is a bit different in my perception


oeps, sorry 😞

👌 4

Nice snarky phrase indeed: >Any sufficiently advanced conventional Event Sourcing system contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half Datomic.


🙂 hope you didn't find it offensive


Not at all, I quite agree too. I think the datom is the right abstraction for 95% of data storage need, I'm convinced.


Just skimmed through the article, as I'm at work doing other stuff, and like very much the case you're making.


@val_waeselynck Thanks for the article. I have a question. Isn't event sourcing usually reactive on the events? It seems like your design requires regular polling via the log API to see what changed.


I think Event Sourcing is agnostic of that, you can consider it an implementation detail. By the way, Datomic on Peers enables you to be reactive too


I'm assuming you are talking about the report queue. Unfortunately the report queue is not really practical. All peers receive the tx report so you need to implement a mechanism to ensure only one of the peer react to the event. You also have to implement a mechanism to support peer restarts and ensure that all your tx reports are processed. I agree that it might be considered an implementation detail but this is an important detail in my opinion if you try to implement event sourcing with Datomic.


Even if that's important to you, it's not like Datomic prevents you from doing that more than any other data store. You can for instance just plug in Onyx and there, you have reactive processing.


There are tons of aspects for which you can say "it's not really Event Sourcing because X", but the whole point of the article is to encourage thinking about ES in a different way :)


I agree with you about thinking abut ES in a different way. And I think you make a compelling case for Datomic tx over application specific events. I was just wondering if you thought about the architectural implications of using the log API in the "Aggregates". Something we often need in this kind of system is speed (reactivity) and coordination across the "Aggregates".


I did, I think if you want high speed convergence you will probably need the help of some external coordination service. That probably takes some effort to set up, but insignificant at the scale of a project imo. That being said, Datomic is not especially designed for low-latency writes, I would not expect to react in under 10ms