daniel-smith/domain-lib

domain-lib's Issues

Document projections library

• Usage of library
• Hooking up events to projections
• Different types of projects that are supported out of the box
• Creating your own projection types
• Sql projections. Upserts, deletes and custom sql
• Sql projections. Table creation - automatic and custom

Add Postgres support for Sql projections

Separate out persistence related concerns from the main DomainLib assembly

Add tracing using OpenTracing API

https://opentracing.io/

Upgrade domain-lib to use EventStoreDb 21.2 and use the gRPC client

Support saving snapshot of aggregate state

This could conceivably be done in another EventStoreDB stream.
When snapshotting is requred, the aggregate state can be serialized in a similar way to event serialization and written to a stream.
Stream metadata can be set to prune historical snapshots if the number of snapshots becomes too large.

Then, when reading, the latest event from the snapshot stream can be read before fetching the events to bring the aggregate state to the latest version.

Note that we will need a way of maintaining the maximum event number contained within the snapshot when saving the data, so as to be able to fetch this information and get only the events after this event number when loading.

Upgrade to .NET 5.0 to allow for serializing/deserializing to events that don't have a default constructor

Support for this has been added to .NET 5.0
dotnet/runtime#29895

Create project templates

It would be useful to have some project templates that help users spin up a new project that uses DomainBlocks. As well as making it easy for users to get started, it can also be a showcase for best practices around how to design a "domain centric" application, using DDD principles.

See https://docs.microsoft.com/en-us/dotnet/core/tutorials/cli-templates-create-item-template

Support for routing commands via a similar mechanism to that for events

Support non-event-sourced scenarios

Improve DB connection management in SqlProjections

Currently, database connections are created in a suitable DbConnector class (implementing IDbConnector)

When an event is handled and dispatched to projections, it may contribute to multiple SqlProjections. That is, we may write to multiple tables in the same database for one event. We would like all of these writes to happen in a single transaction so that we can update a database atomically from an event.

This transaction is controlled by a SqlContext class. The SqlContext class is associated with each event projection and a single SqlContext can be shared across multiple event projections. The SqlContext class uses the connection that is created by the DbConnector.

At the moment, to have things work properly the user must create a single DbConnection that's shared across all projections for the SqlContext to do its job properly.
The user must also ensure that the SqlDialect matches the DbConnector type to generate the correct SQL for the database.

All of this doesn't guide the consumer into the pit of success and we should enhance the API to better guide users to create DbConnectors and SqlDialects in the right way.

Allow serialization to something other than a byte array

For instance, SqlStreamStore uses strings in its API. Domain-lib should allow serialization to this as well as byte arrays

Handle failure cases when saving events to EventStoreDB

Add Event Store persistence layer

Support loading snapshot and subsequent events

Currently, the repository deals with loading a set of events that can be reconsituted into some aggregate state.
This is done by applying those events in order to an initial state.

Once we support persisting a snapshot of the state, see #13, then we can use this snapshot as the initial seed for the state, load subsequent events from the store and apply these to build the latest state.
The API of the method to load from snapshot and events can be similar to that that loads solely from events. The addition of the persisted state is needed.

The load method needs to be able to tell what version the snapshot state is for and then load any subsequent events.

Batch events when loading from EventStoreDB if the number is larger than the max read size

See EventStoreEventsRepository.cs line 45

Add a projections library to handle support for building read models and process managers

Add explicit support for mutable aggregates

Enhance projections to support process managers

This will need an event dispatcher that can acknowledge consumption of events

Add logging at appropriate places throughout the library

Add streaming query support for projections

Maybe use gRPC streaming to push results to clients?

Handle EventStore subscription disconnections

Add EntityFramework adapter for projections

Rather than using raw SQL, we can use an EF DbContext to allow clients to deal with entities directly.

This would help when writing queries against the read model database. The same entities can be used.
One thing to be aware of is performance. If we're hydrating a read model from many events, we'll probably need to look into bulk operations.

EventStoreDB: Persist metadata along with the event

Contents of metadata TBD