Event modelling encapsulation

[bartelink]

If you refer to https://github.com/bartelink/FunDomain/blob/master/Samples/FunUno/UnoGame.fs#L4-L19, you'll see I took the FsUno (not .Prod) codebase and refactored the Event to read as follows:

module Events =
    type Color = 
    | Red
    | Green
    | Blue
    | Yellow

    type Card =
    | Digit of int * Color

    type GameStartedEvent = {GameId: int; PlayerCount:int; TopCard: Card}
    type CardPlayedEvent = {GameId: int; Player:int; Card: Card}

type Event =
| GameStarted   of Events.GameStartedEvent
| CardPlayed    of Events.CardPlayedEvent

(There is no Deck.fs)

I did this for the following reasons:

• too many types are exposed publically (manifests in intellisense in tests)
• because event layouts are schemas I think they should be considered as a whole when designing
• people should be aware they're playing with a contract as they change types
• it's good to be confronted with the fact that Commands are sharing types

The Event type summarises stuff well while not becoming illegible e.g. if you get to 20 events (and have dependencies interspersed with ands etc).

Any thoughts re

1. me (or you) doing a PR to apply this same strategy here? (I'd probably gobble Deck.fs too)
2. removing the Command's reliance on the Events. nested types (I think I'd leave it fr later)

And, wrt #2, should 1) instead push the Events stuff into an Events.fs in preparation for the events of all aggregates being consolidated in a single place?