Support custom aggregator

[tim-cools]

This update makes the event Aggregator fully pluggable. This was not possible because the implementation was used instead of the interface in many places.

I use it to support a different way to build aggregates. (See https://gist.github.com/tim-cools/694ba34dbb93b7a0cdf710886aa29275)

[jeremydmiller]

A couple thoughts:

• Why are you taking in an IDocumentSession? We aren't setting ourselves up for some N+ problems are we?
• One of the reasons I was staying with that concrete Aggregator<T> was so that we could return it in the StoreOptions methods that add the aggregator, then chain a fluent interface behind that so you could add customizations or other steps to the aggregator. If we go for IAggregator<T>, then I think we need a new overload that allows you to customize the basic, concrete Aggregator<T>

[tim-cools]

Good feedback...

• My aggregate contains properties that represent AggregateEvents. So the publish and handling of the events done from inside the aggregate. New events are published to the stream when they are published from the aggregate. I don't want to make DB calls in the build method, but I need the session to add those events to the session.
  Other solutions would be:
  • To store the events in a base class. But I prefer not to use a base class for my aggregate. (http://danielwhittaker.me/2014/11/15/aggregate-root-cqrs-event-sourcing/)
  • To publish the event from outside the aggregate. But I like the fact that the events are published from inside the aggregate.
    You are right that people get them-self in troubles with N+1 problems, but that also applies to other areas like the listeners. It it the user his responsibility. I updated the gist with the Aggregator code (https://gist.github.com/tim-cools/694ba34dbb93b7a0cdf710886aa29275)
• Ah I see. I didn't see any other public members that were used. What other config are you thinking about?

[tim-cools]

Second thought after reading your remark on the chat: it might be enough for me to pass in an interface that allows appending events.

[tim-cools]

@jeremydmiller I believe you not convinced about taking this in. What is holding you back? Is it the passing of the session?

What if I only do the first modification with the IAggregate? This way a consumer can choose how the aggregate is rebuild. I can also look into returning the Aggregator for configuration.

[jeremydmiller]

Sorry @tim-cools, this has been more of a get-around to it kind of thing. I'll have this in soon.

[tim-cools]

@jeremydmiller no worries. let me know if have have concerns...

[tim-cools]

Actually I believe we also have to support the 'events in a base class' scenario as it is often used in examples and DDD frameworks...

I created a separated issue for that: #369

[jvdvleuten]

I don't think storing or publishing events is the responsibility of the aggregate. Complicates a lot of thinks.

[tim-cools]

@jvdvleuten by storing above I didn't meant in database but in-memory in a list, like you did in the example you posted in the other issue by using the AgregateRoot base class. But having to use that base class is something that bothers me for a long time. And about the publish from an aggregate I mostly agree that it increases complexity.

I always look for ways to make my model more pure. So I'm exploring other ways to handle domain events by modelling the events explicitly and let the infrastructure take care of capturing the events and publishing it to to event store...

[jvdvleuten]

@tim-cools that's true. Where in your example are you using the ISession in your Aggregator? Couldn't find it anymore.