Add the nuget packages to the teamcity nuget feed. Add eventstore log output to build artifacts.

How do you implement a saga with AggregateSource? I would like something like Jonathan Oliver's implementation:

public interface ISaga
{
    Guid Id { get; }
    long Version { get; } // for optimistic concurrency

    void Transition(object message);

    ICollection GetUncommittedEvents();
    void ClearUncommittedEvents();

    ICollection GetUndispatchedMessages();
    void ClearUndispatchedMessages();
}

Meet a new citizen

    public interface IEventConverter<in TEvent> 
    {
        IEnumerable<object> Convert(TEvent @event);
    }

Requires that the IEventDeserializer relaxes a bit as well

    public interface IEventDeserializer
    {
        IEnumerable<object> Deserialize(ResolvedEvent resolvedEvent);
    }

All APIs exposing Guid as an aggregate identifier should switch to String. Beware of the fact that we're switching from ValueType to ReferenceType. Provide ArgumentNullException in favor of NullReferenceException.

Similar to what we did for GetEventStore, download, unzip, rename this dependency.

Say hi to InstanceEventRouter and StaticEventRouter

NuGet packages for .NET Core would be nice :)

I'm planning to use F# intrinsics to pretty much all testing/impl of Aggregates a la FsUno.

Within the sample are switchable GES/InMemory 'Store' impl consisting of two [F#] functions:-

• readEvents
• appendEvents

All that's missing from my perspective is a third implementation of those functions :- for NEventStore

I'll probably go to production against NES but obviously the ideal is to either have it switchable to GES when the time is right or at least not have cornered myself abusing NESisms that are going to be fundamentally incompatible.

While the merit of the LCD between them is obviously debatable, it nonetheless is something I am interesting in sweeping to the side for a time.

I'm wondering whether you have future plans/ideas/opinions re extracting an ES repo abstraction as a separate thing ?

I'm not talkiing about starting some superproject that will unify all Event Sourcing impls planet-wide; more like an OWIN-like 'spec' consisting of 2 function sigs with drop-in impls which would be adhere to that common 'interface'

I'm dissecting the code base and I'm assuming the snapshots are sorta following the memento pattern but I can't actually work out from the tests how within this code base its supposed to work.

I can see it follows similar implementations to others Ive seen (ISnapshotable on aggregate / methods to pull and push data to set state)

public void RestoreSnapshot(object state)
    {
      var agg = (MyAggregateSnapshotPoco)state;
      /* mapping data back to agg */
    }

    public object TakeSnapshot()
    {
      return MyAggregateSnapshotPoco{map agg in};
    }

I can't see any logic around storing the memento if version is greater than zero and mod 10 (or similar);
Is there a reason for SnapshotableRepository being a different thing to the repository storing snapshots? I'm guessing the SnapshotableRepository storage as stream should result in a different ident (snapshot_id or something) to avoid conflicting with the aggregate stream but its not enforced (the tests dont clear this up as the names it uses follow the same prefix).

I was wondering if I was misunderstanding the usage as it seems you'd need both and the methods between the two are similar due to the interface but it makes usage less obvious.

Any explanation would be greatly appreciated; I'm looking at various implementations alongside our existing and trying to understand the thought process behind it 😄

Add a project with NUnit Assertion Extensions, so people can bootstrap from there. Lowering the barrier to entry so to speak.

new Scenario().
  GivenNone().
  When().
  Then().
  Build();

new Scenario().
  Given().
  When().
  ThenNone().
  Build();

From a twonversation with @jen20 on twitter: https://twitter.com/jen20/status/361957163750539264

Add support for taking and restoring a snapshot of an aggregate.

Build a set of resources, explore collection api, explore atomfeed, expose them using a NancyModule. The resources revolve around events, streams, causations, correlations, etc ...

When re-hidrating we want the same logic to apply than when changing state in aggregate.

Man, don't do it :)
http://michaelfeathers.typepad.com/michael_feathers_blog/2012/12/global-variables-destroy-design-information.html

Better leave it as per-request object. You create it, you pass it to handlers, and then you commit it. That's it.

Oh, and you don't need Repository. Just having UoW is enough. Communicate with ES from it.

Sorry, I hate that Github still hasn't figured out a way to attach discussions to source files instead of only being able to comment on commits :(