Support NEventStore

[bartelink]

With a small amount of work, the sample could also persist its events in NEventStore in a SQL database.

As I'll be developing a highly similar pair of readEvents / appendEvents, I could add it here, which would serve as a nice test bed (from my perspective).

However the obvious major risk is that adding yet another front end/store (esp if its in the same lib) is going to be the straw that changes the sample from an elegant communication tool to something that misses the point.

So my (obviously very debatable) proposal is for me to split the FsUno project into

• FsUno.Domain (unchanged domain stuff)
• FsUno.Persistence.EventStore (ref to EventStore nuget and GES specific code)
• FsUno.Persistence.InMemory (off on its own)
• FsUno.DemoExe

The major plus would be that FsUno would have a lot less files and the switchable stores becomes clearer

FsUno.Tests would only depend on FsUno.Domain and use NUnit

I'd then write a FsUno.Persistence.NEventStore which FsUno.DemoExe can also reference and then you just switch the store type ref in Main. The lib would:

• have a NES Wireup with perhaps a connection string coming in but not much else as we are not generating a storage abstraction (and when you use NES for storage only, most of the Wireup pipeline is irrelevant)
• have a helper to create the schema if it doesnt exist (NES exposes this and it fits with this being a demo) which one would call from FsUno.DemoExe

The likelihood is that Serialization.fs would be used for Persistence.NES and Persistence.GES. I'd propose to put the file in a FsUno.Persistence but just link to it from the 2x Persistence projects.

But why oh why do all this here?

• I love FsUno.Domain and believe any sane person should def use the approach. But there should be a really good sample which is good enough to use as-is
• I like NEventStore (I have code in prod and am starting a new project that will use it in prod - both on Azure PaaS).
• I like GetEventStore (and will move to it eventually)
• I will be using the DU Serialization you've implemented but don't want to maintain a fork (but would consider using a protobuf.net or FsPickler-based swappable impl if someone contributed that)

What could I do instead?

I could create a bartelink/FunDomain repo with

• Samples/FunUno/Domain (stolen from FsUno)
• Samples/FunUno/Tests (xUnit+Unquote)
• Samples/FunUno/Demo (stolen from FsUno)
• FunDomain.Persistence.NEventStore

The problem is that I can't imagine any traction and I'd just be sowing confusion by having a fork of your serialization (and/or your GES bindings)

I hope I've explained myself sufficiently for you to decide quickly which direction you'd like this to take - open to any subsets you consider reasonable and definitely will understand if you say "Don't go toppling my nice tidy sample please!"