eventSourceable mixin

[rhyslbw]

Motivations:

1. Apply the trait to domain.Entity, remove the need for a formal Aggregate class
2. Reposition eventSourcing.Process as domain.Process
3. Remove domain directory in space:event-sourcing https://github.com/meteor-space/event-sourcing/tree/develop/source/server, so it's positioned as an infrastructure package building on space:domain

I feel this will set us up for making Space's domain implementation less dependent on applying ES for every sub-domain.

Issues:

• How to handle the Process additional behavior - Extra mixin? If so how can we describe this trait?

[rhyslbw]

@DominikGuzei What's your opinion of this one? I really feel it needs to make the 3.x release since a breaking change here will impact data.

[DominikGuzei]

Yeah this is a breaking change … so major version is necessary

[rhyslbw]

…right, but my point is we'll need to hold off on 3.0.0 until this is done, and we're wanting to launch new projects on the 3.x track, so it's now or never

[DominikGuzei]

Yeah, we should include it.
re: Process additional behaviour, i would just add it to the EventSourcable mixin for now. There never was a really good distinction between Aggregates / Process in our package anyway.

[rhyslbw]

Agree. It's more of a concept, so we can actually get rid of the API and just include this in training and education

[rhyslbw]

Ok so as discussed this has been punted to the next major release due to the breaking changes and priority to get 3.0.0 out. A mitigating action is to name snapshot types using the class name, as this will be forward compatible. However, as the snapshots collection is an ephemeral cache, it can be rebuilt on demand without impacting the system's integrity.

[rhyslbw]

Have been thinking about this issue with @qejk in some depth, and now have more thoughts. Below is what we settled on:

We feel the best approach is to keep the current class and not extracting the functionality to a mixin since we really do need the concept of an aggregate class here but not in space:domain. Same goes for Process as it's fine being an extension of Aggregate with the additional ability to trigger commands.

Not related to this issue, but the real improvement we can make is to make Space.eventSourcing.Aggregate extended from Space.domain.Entity :-)

Thoughts @DominikGuzei @darko-mijic ?

[DominikGuzei]

Yeah while "working" on it, i also had the feeling that this probably won't bring many benefits apart from "being more generalized" (which is not a benefit in itself). In general i would suggest to use mixins for only for stuff that is truly generalizable / can be applied to many different contexts / classes.

[DominikGuzei]

Closed in favor of #63

[rhyslbw]

@samhatoum raised a use-case in Slack for extracting the functionality to a plain object, so you don't have to use Space classes for your aggregate. I agree this would be a good move and make Space ES more accessible.

Food for thought:
http://raganwald.com/2015/06/17/functional-mixins.html

[DominikGuzei]

Hmm … not too sure about how we can keep all the things together while moving away from Space.Object, which provides a lot more options than a simple Object.assign call (e.g: onMixinApplied, onDependenciesReady callbacks, as well as hasMixin methods etc.). Another option would be to split up the space:base repository and extract useful concepts into node.js packages. Most code in space:base could be extracted as it has little todo with Meteor.

[rhyslbw]

Another option would be to split up the space:base repository and extract useful concepts into node.js packages

👍 This would be a solid move