Example app and service templates `dotnet new -i Equinox.Templates; dotnet new eqx*/pro*` https://github.com/jet/equinox https://github.com/jet/FsCodec
This applies a set of code patterns that I've been applying in recent times in a system I'm building that consists of the following elements:
the Domain project defines a module Config which defines a Store DU which defines the set of stores its connectable to. This would be Memory plus one or more concrete ones
Each module Aggregate has a module Config which surfaces a create method that is passed a Store DU instance and does the appropriate wiring (e.g. if using Cosmos and Snapshots makes sense, it means that logic is close to the aggregate)
the Domain project needs to reference the relevant concrete store package e.g. Equinox.CosmosStore. NOTE there should be no logic in the Domain project actually connecting to the store - this is purely to allow one to wire the specific ways the caching or snapshotting needs to work per aggregate in a single place
When Domain is organised in this manner, the following becomes clean to do:
a) define high level tests that operate in-memory which exercise significant workflows in a system (often cross-aggregate), using a Memory Store
b) define integration tests that use the concrete stores
c) define Web host and/or Reactor apps without repeating wiring logic (if it needs to be shared, a .Infrastructure project can have that specific wiring)
A better demo app is needed, and will arrive in due course; for now, the closest thing is the layout of the equinox-shipping project
This applies a set of code patterns that I've been applying in recent times in a system I'm building that consists of the following elements:
Domainproject defines amodule Configwhich defines aStoreDU which defines the set of stores its connectable to. This would be Memory plus one or more concrete onesmodule Aggregatehas amodule Configwhich surfaces acreatemethod that is passed a Store DU instance and does the appropriate wiring (e.g. if using Cosmos and Snapshots makes sense, it means that logic is close to the aggregate)Equinox.CosmosStore. NOTE there should be no logic in theDomainproject actually connecting to the store - this is purely to allow one to wire the specific ways the caching or snapshotting needs to work per aggregate in a single placeWhen Domain is organised in this manner, the following becomes clean to do: a) define high level tests that operate in-memory which exercise significant workflows in a system (often cross-aggregate), using a Memory Store b) define integration tests that use the concrete stores c) define Web host and/or Reactor apps without repeating wiring logic (if it needs to be shared, a
.Infrastructureproject can have that specific wiring)A better demo app is needed, and will arrive in due course; for now, the closest thing is the layout of the
equinox-shippingprojectIncludes:
asyncsupport