Separate Event Sourcing and DDD from infrastructure

[rkaw92]

Currently, the scope of esdf is that it defines an EventSourcedAggregate class, the Event and Commit data transfer objects, several utilities and a loading mechanism (tryWith). Thus, a few unused files have been laying in the repository simply because esdf has once tried to be a full-fledged DDD/CQRS/ES solution. The presence of legacy code has somewhat impaired improvement to the core event sourcing-related APIs.

I am now going to change that by splitting this framework into several loosely-coupled and independent modules, starting with the Event Sourced Aggregate.

Major changes planned after the split:

• Final removal of EventSourcedAggregate#commit - it is the repository's responsibility to persist and rehydrate aggregates
• Breaking API changes for Event and Commit to enable sane property names (no more smurfs such as eventType and eventPayload in Event)
• Easier event handler API - function(payload)
• Explicit and simplified snapshot support API for aggregates - no more commenting out of _applySnapshot or _getSnapshotData

Not decided yet, but probably nice to have in the long run:

• Immutability support - externalized aggregateID passing and event staging
  • Forced immutability of state via Immutable.js?
    • Potentially a memory-heavy solution
    • Troublesome JSON snapshots
    • Breaks ES6 destructuring
• Separation of Aggregate Root functionality from Event Sourcing
  • Universal repository that defers to strategies (e.g. Event Sourcing persistence strategy, change detection + CRUD persistence strategy?)

Not going to do in the separated module:

• Streaming/dispatch - this should be a concern external to the Aggregate Root itself
• Commit metadata visible from event handlers - the base AR logic should not have a notion of Commits as they are an Event Sourcing concept just like Events