4 ms·
The cognitive struggle I have is how not only 90% on reads I need the last version, but also on write. The classical example is how avoid duplicated data or do
by mamcx 10y ago
The cognitive struggle I have is how not only 90% on reads I need the last version, but also on write.
The classical example is how avoid duplicated data or do validation across tables. One of the requirements of my app is deny a sale if the customer have pending invoices. The tricky part with invoice is that entry must be fast (I'm competing against DOS apps that fly at data-entry).
So when ES say "Record the event, then build the read side at later time", instead me (and I think, many of us) wanna the opposite "Put into the event log after we have do validations".
Of course, some actions can be delayed, but some need be as-now. How do this elegantly?
My initial attempt is code against the tables and use triggers for recording the story, but that is not as nice...
- yrashk 10y agoThis is actually how I do event sourcing in many ways. The entry happens through commands, which can do validations prior to emitting a stream of events to be journaled. I also expose a locking mechanism to commands so that they can ensure the uniqueness or property validations are correct. In lazy event sourcing, you don't "build the read side at a later time", it's built upon receipt — in a form of indices, as they are THE read side and you pull this data and form domain objects on demand (by querying your indices), just transforming one representation (relevant events) into another (domain objects). Does this help?
- mamcx 10y agoHow you "expose a locking mechanism to commands"? And how you build the indices?