How to use J Oliver's EventStore library?

2
votes

I've been looking into Event Sourcing for a new project with J Oliver's EventStore and mongo as the persistence layer but have come across a few questions:

  1. Previous to trying event sourcing my domain persisted to a db and I've been using Udi's domain events pattern which has worked really well for me with NHibernate managing the unit of work. However I've ended up with one unit of work that can affect more than one aggregate eg.

    I "checkout" my shopping basket aggregate which raises an event for which a handler responds by creating an invoice aggregate which in turn raises an event (this is an example only)

    In this case I have one unit of work that alters two aggregate roots - in the event store I could get the events raised added to two different event streams but they would not be persisted in an atomic way (the first could succeed and second fail). So what do people do to aviod this from happening?

  2. On the github home page it suggests that you can use a fluent interface to configure the EventStore, however when I download the source, compile it and look in the example the wireup class doesn't seem to be available - is it in a different branch? (I have master)

  3. What is the recommended way to handle the IStoreEvents impl? As a singleton similar to Nhibernates session factory?

1
cqrsneventstore
On Stackoverflow it is a good practice to ask one question per post. You'll end up with better answers because it is easier to post answers to one question, easier to upvote good answers, easier to find this post since you can give it a more descriptive title, etc. In any case, good questions! – Brian Low

1 Answers

5
votes

  1. You've actually got multiple units of work occurring in the example you gave. When an aggregate is modified it dispatches an event. Something else listens to that event and handles another unit of work and so on.

    The way the EventStore is designed, it can still accommodate your scenario but it would be three separate units of work. You would just plug in Udi's DomainEvents "Salvation" solution into your own implementation of IPublishEvents and run that inside of the AsynchronousCommitDispatcher. In true DDD a single aggregate is a unit of work--by definition this is the consistency boundary.

  2. About 8 hours ago I did a push that has the fluent stuff as part of the compilation. Try pulling down the latest from master.

  3. IStoreEvents is designed to be multithreaded so you can safely configure it as a singleton within your application. When you open a session from IStoreEvents, the session is single threaded and should not be shared across threads within your application.