﻿Overview
========
(see http://www.martinfowler.com/eaaDev/EventSourcing.html )
Event sourcing is a way of storing data as a sequence of events that have happened to an entity rather than storing a 
snapshot of the current state of that entity.  For example, in event sourcing an account would have a sequence of events 
which when played would give you a balance rather than storing a snapshot of that balance and updating it.

(Also more detail at http://www.codeproject.com/Articles/714742/CQRS-on-Windows-Azure-Event-sourcing )

Aggregate
=========
An aggregate (also sometimes referred to as an aggregate root) is a way of uniquely identifying something that events can occur to 
and which we wish to track as part of our business model.

Every aggregate must have an unique identifier, or a system provided unique key (this could be an incremental integer or a GUID).

Aggregates may be organised in a hierarchy or may be completely independent of each other, depending on how the business is organised.

Aggregates should have additional commentary in human-readable form for documentation of the system. 

Aggregate definitions can also feed into the web service query formation in a similar way to the way CRUD based systems do this with 
the hierarchy reflected in the URL.

Implementation
--------------
 Every aggregate class in the system has a strongly typed marker interface (IAggregate) which also defines what the key of the aggregate 
 is. This key must be provided in the class constructor and be immutable.

Event
=====
An event is a record that something of interest happened to the object identified by the  Aggregates (Aggregate roots).

Events are stored in order of occurrence and this allows for the most powerful aspects of event sourcing - the ability to recreate 
the state of your object as it was at any given point in time by replaying the events into it. (These views of the state of an aggregate 
when events are applied are generated by  Projections).

Each event can only be linked to one aggregate identifier.

Each event type must have an unique name of be uniquely identifiable.

Behind the scenes a sequence and timestamp property are added to indicate the order in which events were recorded and the relation between 
this and real-world time.

Implementation
--------------
 Events are defined by a marker interface that specifies the aggregate root type that this event applies to. The event class is marked as 
 "NotInheritable" (sealed) in order to keep the event model clean.

 An event is a lightweight class (POCO) that holds the properties recorded about the event that occurred.

 Projection
 ==========
 A projection takes a stream of  Events that were recorded against a given  Aggregates (Aggregate roots) and uses them to create a view 
 of the state of the object that the aggregate represents as at a given point in time.

 A projection can only apply to one aggregation identifier.

 A projection must have an unique name.

 A projection can filter which events it does or does not process - events which have no impact on the state of the projection can be 
 ignored.

Implementation
--------------
 These are identified by a mark the class as being a projection "(IProjection)" and also one or more strongly-typed interfaces to indicate 
 the events that the projection processes "(IHandleEvent(Of TEvent))"
