Tibor, Jiri, Thanks for putting effort into this.
A bit more is needed to actually include the documentation in Zest. For example, some assembly guidance would be a huge plus. For now the non-existent documentation is split across: - libraries/eventsourcing/src/docs/eventsourcing.txt - libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt - libraries/eventsourcing-rest/src/docs/eventsourcing-rest.txt But, like it's done for SQL libraries (libraries/sql-*), we can put the EventSourcing documentation in a single file/page. See libraries/sql/src/docs/sql.txt for a sample. This would mean putting your documentation covering the three eventsourcing librairies in `libraries/eventsourcing/src/docs/eventsourcing.txt` removing the two other files and their inclusion in `manual/src/docs/userguide/libraries.txt`. Or, we can keep the three files/pages, whatever suits your contribution mood :) Ping me if you need anything. Cheers /Paul Jiri Jetmar a écrit : > Hi Tibor, > > sorry for the late answer, I somehow overlooked your proposal in the flood > of other Qi4j notifications.. :-) > > Pls see my comments below : > > 2015-07-09 3:12 GMT+02:00 Tibor Mlynarik <[email protected]>: > >> Hi Jiri, >> >> pls review my findings about eventsourcing library. >> >> I see whole library as nice building blocks from which one can build >> solution for decoupling between external systems/subsystems. >> > > As I understood the idea behind event sourcing, the purpose is to > trigger/generate an event whenever the state of an application has been > mutated. > > On can generate events on very different levels in the application, but I > would see the main benefit somewhere very close > to the entities, typicaly directly in the domain model level. > > >> To support reproducible entity store I am not sure. >> > > Yes, the general assumption is when you have something like a event-store > and you are going to resend (or replay) all of the > previously sent domain events one would be able to reproduce 1:1 the entire > domain model state. In the > practical implementation one would need a kind of snapshotting mechanism, > otherwise you are going to resend always > anything from event n(0). > > We are using for now the event sourcing mechanism mostly for > history-keeping purposes. So any mutation > of the domain model generates an event that is routed using a messaging > infrastructure to a dedicated > history-keeping domain model, that uses the same code base (including > versioning) as the original model. The nice > side-effect is that one can use different storage technology for the online > DM and the history-keeping DM. > > Cheers, > Jiri > > > >> thanks, >> >> Tibor >> > > Thank you Tibor, I think your description is fine. We do not need to > explain the theory behind ES, but the implementation details of Qi4j, what > you did. > > >> * Overview * >> Library supports generating, storing and replying two types of events: >> application-events and domain-events. >> >> Application events are bound to usecase and are produced by execution of >> specific methods ( ones with ApplicationEvent as their first parameter ) >> Each application event holds information about usecase, method name and >> json serialized values of method parameters. >> >> Domain events are bound to entity instances and are produced by execution >> of annotated ( see @DomainEvent) method that belongs to EntityComposite. >> Each domain event ( see DomainEventValue) holds information about entity >> type, identity, method name and json serialized values of method parameters. >> >> Both application and domain events are captured during UnitOfWork lifetime >> and are stored in event store after successfully completed UnitOfWork as >> collection together. ( see UnitOfWorkDomainEventsValue and >> TransactionApplicationEvents). >> >> There is support for replying events. When events are replied the same >> code is executed but no new events are generated. >> >> Event store supports indexed and streamed access to events feed. There is >> in-memory and JDBM backed implementation. >> For remote access to feed there is eventsourcing-rest library that exposes >> events as Atom feeds. >> >> There are helper classes that enables a service to easily track event >> feed, and >> for domain events there is event router that allow specify >> specification->receiver routes. >> >> * Not not so good parts, limitations * >> >> Application events part seems to be not finished. >> ApplicationEventFactoryService has wrong concern associated. >> There is only abstract base for event store ( thought should be easy >> copied from domain events). And missing tests. >> >> Parameters serialization and deserialization seems to be not symmetric in >> supported types. >> >> There is support for events reply , but there seems to be those >> limitations for domain events: >> >> - all entity mutations has to go via annotated methods, otherwise one >> cannot rebuild entity state fully >> - no support for entity removal >> - no suport for entity properties constraints ( blank entity instance is >> created when it's id is not existing yet) >> - limited support for parameter types (?) >> >> as for application events mapping from usecase name to target instance has >> to be managed somehow. >> >> * Blog post + slides * >> >> [1] >> http://www.jroller.com/rickard/entry/application_event_distribution_through_rest >> [2] http://www.slideshare.net/Rickardberg/eventsourcing-applied
