Hey,
If you're on the DDD Yahoo mailinglist you will have seen the
discussions about CommandQuerySeparation and EventSourcing lately.
EventSourcing is defined by MF here:
http://martinfowler.com/eaaDev/EventSourcing.html
During the persistence refactoring I realized that all our EntityState
changes can now be captured as events, and I even have an EntityState
implementation that does this. Me and Michael have also been talking
about doing event-based entitystores. When it comes to building scalable
applications that also have a need for auditing this would be extremely
convenient to have.
All this taken together I think we have a unique opportunity with Qi4j.
I think we could essentially change EntityStore.prepare() into:
prepare(EntityStoreChange)
where EntityStoreChange captures a series of EntityStateChange, each of
which contains the id, what happened, the value, and the usecase name.
Example:
"123, set property, name, Rickard, 'Update name'"
The usecase name we get for free since UnitOfWork is created with a
Usecase that has a name. We might consider removing the method that
takes a default Usecase, just to encourage always setting a name for
auditing purposes.
The EntityStore would then take the changes and apply them to the store
to get the persisted stated into a synced up position. If the events are
also stored separately this becomes a way to get read-databases synced,
to get indexes synced, to get audit logs, and other similar things. What
helps for us, compared to what MF writes about, is that the processing
is already done, so the event that comes will always have the same
effect and not require external or internal resources. It is more like
the Subversion example that he noted.
A naive implementation would store the EntityStateChanges using the full
data as indicated above. A more sophisticated version would be that the
EntityStoreChange contains the usecase name, that repeated sets of the
same property are coalesced, and that repeated updates of the same id is
done once. This can be represented in XML as:
<usecase name='Add child'>
<entity id='123'>
<setproperty name='name'>Rickard</setproperty>
<setproperty name='age'>33</setproperty>
<setassociation name='childof'>456</setproperty>
</entity>
<entity id='456'>
<addmanyassociation name='children' index='0'>123</addmanyassociation>
</entity>
</usecase>
---
Do this in binary to make it more compact on the wire. This can then be
expanded to the full format when applied.
But what about the main idea? For/against? It would make Qi4j inherently
EventSourced, and also almost trivially BASE-oriented. For my own
selfish purposes (as I need scalability + audit logs) that would be very
attractive.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
