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 > > > On Jul 8, 2015, at 1:34 PM, Jiri Jetmar <[email protected]> wrote: > > > Hi Tibor, > > > > I;m also not an expert of the ES lib, but evtl. I would be able to > > review/give a feedback > > an your proposal. > > > > Cheers, > > Jiri > > > > 2015-07-08 13:05 GMT+02:00 Tibor Mlynarik <[email protected]>: > > > >> It takes me some time to understand this lib ( as I am not user of it ) > , > >> but hopefully I will come with some docs later today. > >> > >> cheers, > >> > >> Tibor > >> > >> On Jul 8, 2015, at 12:57 PM, Niclas Hedhman <[email protected]> wrote: > >> > >>> Ok, I withdraw this suggestion then. Hopes move to Tibor to help with > >> some > >>> basic docs. Any other volunteer is appreciated. > >>> > >>> On Wed, Jul 8, 2015 at 1:29 PM, Jiri Jetmar <[email protected]> > >>> wrote: > >>> > >>>> Hi Niclas, > >>>> > >>>> we are using it on the DM/Entity level. Any C(R)UD interaction uses > >> Domain > >>>> Events. In fact the Entity i.) triggers the Event and consumes it at > the > >>>> same time in order to mutate its state. > >>>> > >>>> So pls let it in.. :) The Domain Event Library is indeed not perfect, > >> but > >>>> at least for us robust enough to be used. > >>>> > >>>> Thank you. > >>>> > >>>> Cheers, > >>>> Jiri > >>>> > >>>> 2015-07-08 11:57 GMT+02:00 Niclas Hedhman <[email protected]>: > >>>> > >>>>> I have briefly reviewed the eventsourcing codebase, and the immediate > >>>>> feeling I got was; "This should be with Java 8 Stream API". > >>>>> > >>>>> So, I think we should simply mothball (drop from settings.gradle) the > >>>>> eventsourcing libraries and resurrect it somewhere in 3.x when we > have > >>>> Java > >>>>> 8 available. > >>>>> > >>>>> If anyone is depending on this library (I assume that StreamFlow uses > >> its > >>>>> own implementation, and still depend on Qi4j 1.4.x), then raise an > >>>>> objection (together with some docs ;-) ) > >>>>> > >>>>> > >>>>> Cheers > >>>>> -- > >>>>> Niclas Hedhman, Software Developer > >>>>> http://zest.apache.org - New Energy for Java > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Niclas Hedhman, Software Developer > >>> http://zest.apache.org - New Energy for Java > >> > >> > >
