3 ms·
Silly question: isn't the way you're supposed to handle the observer pattern thing to be that you can follow processing chains using correlation IDs? Ie. the in
by FeepingCreature 5y ago
Silly question: isn't the way you're supposed to handle the observer pattern thing to be that you can follow processing chains using correlation IDs? Ie. the initial event of a dataflow gets tagged with a unique ID and then there's some database magic that lets you track that ID through the system? Like, I can see where that would go wrong once you merge multiple events together, but that seems a different failure point than described here.
And while we're at it, the whole point of eventsourcing is that they're not supposed to model "internal" process state? They're supposed to be the ground source of truth; whatever the process has to do to mangle that into a model it can work with should be no skin off the events' back.
The rest seems very, very correct to my experience. Especially not knowing the pain points until you're past the toy level.
- ggm 5y ago"Database magic" is worrisome
- FeepingCreature 5y agoEh, you could do it manually by hanging a projection on $all and republishing to streams per correlation id. But it's cheaper to let the db do it internally.
- ggm 5y agoSo it's not a strict dependency, more in the spirit probably of an optimisation: "here's how you own it, but most people let the substrate do it for you..." type thing.
- adamauckland 5y agoYes, Correlation ID/Activity ID/Request ID, you need something that ties the event together. I think Event Sourcing is an amazing model for certain scenarios. Often, a hybrid approach can be better.