Am 13.12.2012 um 20:36 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Sure :) I think this approach has some benefits. �Normal objects can be seen as the only and most actual snapshot of a state changing history. The history gets discarded immediately. But this history has a great value in itself being able to replay/undo things or develop new values that can be applied at a later moment. We just need to look at the debugger. A stack or context chain is just a collection of moments in time. If you go up the stack we go back in time. But objects stay in the now. It would just be perfect if the object state would go back in time as well.
> On 13 Dec 2012, at 17:56, Norbert Hartl <norbert@hartl.name> wrote:
>
>> Am 13.12.2012 um 17:27 schrieb St�phane Ducasse <stephane.ducasse@inria.fr>:
>>
>>>> Hi all,
>>>>
>>>> Please, anyone knows a Pharo framework to implement CQRS and/or Event Sourcing?
>>>
>>> I read in diagonal the paper of martin fowler and I would say just some command patterns?
>>> + some meta modeling?
>>> no?
>>
>> Well, you can give that particular answer to _a lot_ of problems :) I think the important part is the "event store" and how you snapshot state. So it is more or less a persistence question. Staying in-image it is rather easy. I use an approach where I still have the business objects holding state. But state is altered through commands and every command emits a set of events that get written to a timeline. The objects analyzing the timeline are more CQRS like because the state evolves out of the timeline. So I have an
>>
>> Event class with instVar time (aDateAndTime)
>> A timeline is a sorted collection (by time) of events.
>> An object has a stream on the timeline. Its position is the positional information about the snapshot state.
>> Snapshot state is updated by following the stream (next: 100, upToDate: � upToEventType:�)
>>
>> Altogether you have sources that put events on the timeline. Separated from that you have the consumer that reads the snapshot state and updates it.
>>
>> Norbert
>
> Sounds really cool and exciting, Norbert.
> I think many people including myself are thinking along those lines.
> Next time we meet you'll have to show me ;-)
>
Let's take a networked service as an example. If we look more closely we can see a snapshot of data is about actuality and consistency. We always like to have consistent data. But actuality is ambiguous in a concurrent media with non-deterministic latencies like the internet. If we separate these we find the need to have data that is consistent at any point in time. But reading the data does not have to return the newest state available.
So we divide the process into three things: adding state change, updating state snapshot, reading state snapshot. The adding is an append-only operation that can be done in a very fast way by the persistence and has less issues when it comes to concurrency. Updating the state snapshot from the state change events can be done according to the needs for actuality or performance. Just to make it clear: In this approach there is also just one entity that is updating the state, so more concurrency problems solved. Finally reading the state can be done in multiple ways. Either you read the provided snapshot or you update the snapshot to the newest value in your private copy of a state holder. This time again you are not changing something concurrent.
A more real life example is one of our products. I changed to model to emit events 6 month ago. Well, using GemStone I didn't have to think about persistence. It is just a persisted collection with a few million events in it. 3 month _after_ I started to collect events I started to think about what data I actually need to show on the web UI. Having all the history in my hand I can derive plenty of different values just afterwards. Every value has a stream on the events collection. So every value has its own cursor in history. New values just start at the beginning of the collection and catch to now. Old ones have just little to update.
I hope this is useful somehow,
Norbert