Add Location Series example

[bartelink]

This PR illustrates an approach to deal with long-lived streams without having them actually be infinite, which involves:

1. a LocationEpoch which maintains a rolling balance

• each successor deterministically has the balance carried forward written as the first event of the stream
• there's a Closed event, after which no writers are permitted to write

2. a LocationSeries aggregate which holds a pointer to verified active epoch (competing readers/writers read this optimistically on a cached basis; in the event that they're behind, they'll compete to log the successful commencement of a new epoch, which cannot happen before the CarriedForward event for the successor epoch has been committed)

TODO:

• converge with https://github.com/jet/equinox/blob/master/samples/Tutorial/AsAt.fsx (fold needs to hold and/or snapshot balances at each point in time as transfers can reference a specific point in time)
• determine an appropriate way to define a reference to such a point in time (LocationEpochId + event index within the epoch?)
• tests (should have commonality with approach used in Add Sample Aggregates; naming consistency #174)
• probably move to github.com/jet/dotnet-templates (not least because build is failing due to duplicate Domain.fsproj files in sln)

🤔is tranche a better term for this than epoch?

[swrhim]

Any reason these parse/next/tostrings are not just member functions of the type?

[bartelink]

The 'type', being a type alias, only exists at compile time, so there's no type to augment as such

[swrhim]

Generally these timestamps are represented as "m/mss/" with slashes going the other way. Is it the opposite way outside of the US? Or is this just escaping the character?

[bartelink]

escaping the char (this is a stray commit that shouldnt be here!)

[swrhim]

Why 20 minutes? Is this default? If so, can we make it explicit?

[bartelink]

generally, this should be something that makes sense in the context of the actual app - in many apps, where there's not a lot of state being computed, longer timespans may be perfectly appropriate (the 20m random number originally derives from interaction patterns for the Store's carts). The more significant factor is of course that the Cache has a max size, and stuff gets dropped in LRU order

[swrhim]

Would each service have to implement a version of this to be able to consume these long running streams?

[bartelink]

This shows a protocol for having writers cooperatively write to a series with a long-running state. Typically you'd expect a given BC to encapsulate access to such streams from the write perspective.

To manage reading, there are any number of ways of covering that, depending on need:

• one thing that would work is to publish state via a summaryProducer
• alternately, as the test demonstrates, you use the same process as one applies for writing in order to determine the current state

In both cases, you'd likely conceal the fact that the representation uses two categories internally to realize the implementation.

[bartelink]

Moving to jet/dotnet-templates#40