Event Patterns
Recorded at:
Unlimited undo
by
Mikko Apo
Sometimes I've been thinking how the same solution would work as a backend solution for large scale enterprise data. Storing the change information would be nice step up from having just the current state of the model available in the database.
Every change in the model could be stored as event. The event could contain more information about the transaction than just the change data: user id, transaction ids, session state and application's context. With that info the event log would have more uses than "just" containing the changes, it would serve as an automatically generated application/system log. Event's authentication data could would provide accountability for all actions. Also, as a convinient side effect the system would support data's revision history out of the box. No more need to manually reimplement different aspects of data's revision history.
Hooking something like this to the integration layer would be nice. Persistance APIs like JPA could also generate the event log automatically. That way the system would be nicely transparent (from the application's point of view) and there wouldn't be any need for changes to support the event log.
patterns!
by
Joost de Vries
I still feel that patterns are a wonderful way to create knowledge: ie make explicit what people have been doing wrestling with real world problems.
(if I'm not right in saying that the patterns movement dried up I'd love to see some some pointers)
So, this is very interesting.
State transitions as event transaction model
by
William Homan-Muise




Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think