Multiple event stores in modular monolith?

[boom-morten]

I am creating a quite complex system in a modular monolith setup. All modules are decoupled as far as practical, and they interact through messaging and events on a bus. Internally I want to use event sourcing for at least a few of these modules, but since they are all running in the same host, I am not sure how to initialize Cratis Chronicle. The default Asp.Net config extension only allows for one EventStore.
I could set up only one store and move on, but since each module has its own variant of their ubiquitous language I would prefer to have separate stores to avoid having to compromise on event names in case it would collide with something from another module.
So this is as much a design question (I am new to both proper DDD and event sourcing), as a technical question: Should I bother with having multiple stores at all from a design perspective? And if multiple stores is the right approach, how would I go about configuring this on a single host?

[einari]

Sorry for very late reply on this, it completely flew under the radar.

The default configuration of Chronicle is as you say to hook up the IoC for IEventStore and such for one EventStore type of scenario. In a way assuming you will divide your modules into separate processes.

As a general rule of thumb, I would say that separating out per module is a good idea as it then enables you to in practice also in the future to run them as separate processes / containers if one wants. What we tend to think is a good idea is to start by identifying the boundaries and DDDs bounded context is what we lean towards to guide us.

That being said, decoupling at a module level introduces new complexities in terms of communication between different modules. This is where we tend to talk about the inbox <-> outbox pattern where one module would be producing "public" events that are not the same events as your "private" events and put these in an outbox. Any other module could then be subscribing to this outbox and get a copy of them in an inbox specific to the source. We don't have this formalized in Chronicle just yet, but the design and issue is ready and something we will have in the near future (#1473).

Going back to the original question of then having multiple event stores in one process. The ASP.NET setup we have today doesn't have anything for it. But I can absolutely see the use case for it. If you want an automated hook up, it would need to be able to understand context. One way could be to introduce a required HTTP header (e.g. x-module) that would then be used to resolve which event store to use. For Chronicle, we could have a way to configure this by adding a "discriminator" strategy to the setup where you could chose the strategy and for HTTP header, chose the name of the header.

Let us know what you think.

[Petteroe]

Thank you for the reflections here. And apologize for being late to your late response 😉

Having support for multiple event stores in one process might be only required for a small audience like me, but when building a startup solution in a modular fashion for "future proofing" while still keeping deployment as cheap and easily managed for a non-ops guy like me.

As for the discriminator you mention, if there is a way to have a customizable strategy that can be used for this it would be awesome. For example, I might not want to use the header but as I have a predictable grouping (root path) of my endpoints, I could use that instead.

And also, I am already using Masstransit for the "public" events between modules/contexts so in my mind that doesn't necessarily have to be the concern of Cratis. That does, however, mean that actions are not only triggered by asp.net endpoints, but by any handler of these public events. It might not matter much, but maybe it will impact things like the causation stuff. (As you can tell, I am a noob in this world and haven't got the lingo down just yet)

[einari]

I don't see anything wrong in us supporting the scenario you describe. Basically what we could be offering is a way to configure the ChronicleAspNetCoreOptions that would bind using keyed services.

We could do something like the following:

var builder = WebApplication.CreateBuilder(args);
builder.AddCratisChronicle(options => options
    .AddEventStore("MyFirstEventStore")
    .AddEventStore("MySecondEventStore"));

You could then be consuming this in the following way (e.g. in a controller):

public class MyController([FromKeyedService("MyFirstEventStore")] IEventStore eventStore): ControllerBase
{
}

If you think this would work, you could then do this yourself till we have it supported by basically doing what we do in the ChronicleClientServiceCollectionExtensions but use the keyed versions of it:

services.AddKeyedScoped("EventStoreName", .... ) // For the IEventStore

services.AddKeyedSingleton("EventStoreName", sp => sp.GetRequiredKeyedService<IChronicleClient>("EventStoreName").ArtifactsProvider)