Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Message-ID: <55A8F332.5000502@nosphere.org>
Date: Fri, 17 Jul 2015 14:21:06 +0200
From: Paul Merlin <paul@nosphere.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@zest.apache.org
Subject: Re: [Proposal] Drop EventSourcing for 2.1
References: 
 <CADmm+Kec80FyrefPvJ++Kr1eC6pKsh+_6+YHSLtxbUQsTqMmng@mail.gmail.com>
 <CAH+CGsJSOiKfiJUKGc7LgoBzjJosPDE2Qkva1+LNSy=z0jSWCA@mail.gmail.com>
 <CADmm+KeBecNt4iH10sRoDD0vuX24+6A3qzifCP=d-ExSQ9wu2g@mail.gmail.com>
 <089C9C90-A581-4445-9890-2C59C2766091@gmail.com>
 <CAH+CGs+uFmoASBkWF4xeRwaNvC6o6JryLHUDUn0gOP0+NChECw@mail.gmail.com>
 <6A5FD4E9-65FD-46DE-A5EB-124730FC4C58@gmail.com>
 <CAH+CGs+7C8QZbHmcuQ1pYCoxbFvsvJ9ZUHEcYu-G6DdpUcNNDg@mail.gmail.com>
In-Reply-To: 
 <CAH+CGs+7C8QZbHmcuQ1pYCoxbFvsvJ9ZUHEcYu-G6DdpUcNNDg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------060003010201070100090406"

--------------060003010201070100090406
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =C3=A9crit :
> Hi Tibor,
>
> sorry for the late answer, I somehow overlooked your proposal in the fl=
ood
> of other Qi4j notifications.. :-)
>
> Pls see my comments below :
>
> 2015-07-09 3:12 GMT+02:00 Tibor Mlynarik <tibor.mlynarik@gmail.com>:
>
>> 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-sto=
re
> and you are going to resend (or replay) all of the
> previously sent domain events one would be able to reproduce 1:1 the en=
tire
> domain model state. In the
> practical implementation one would need a kind of snapshotting mechanis=
m,
> 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 on=
line
> 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, w=
hat
> 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 an=
d
>> json serialized values of method parameters.
>>
>> Domain events are bound to entity instances and are produced by execut=
ion
>> of annotated ( see @DomainEvent) method that belongs to EntityComposit=
e.
>> Each domain event ( see DomainEventValue) holds information about enti=
ty
>> type, identity, method name and json serialized values of method param=
eters.
>>
>> Both application and domain events are captured during UnitOfWork life=
time
>> 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 exp=
oses
>> 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_th=
rough_rest
>> [2] http://www.slideshare.net/Rickardberg/eventsourcing-applied


--------------060003010201070100090406--