-
Notifications
You must be signed in to change notification settings - Fork 22
Description
At this point, Reactive-Domain only manages instance streams/aggregates (every time you create a new stream, you tag it with an Id, then reference the Id each time you need to work on the aggregate).
We have the case for items, such as Roles
, or Facets
, where you have a rather limited set of events in the lifetime of the system, and to create a series of streams to express each Role
or Facet
is utter insanity (10 streams of 2 events each that are established when you deploy, and most likely never touch again).
Chris saw my workaround, which is to create a Guid in the system shared on a Constants
static class that is used to retrieve this global stream in all instances. The discussions that he and I had surrounding this is that he cringed when he saw it. He understood why, but felt like it was in poor taste and didn't want to have it that way ongoing.
I think there is a way to rather elegantly make a change that the current "Api" would not change, and provide this functionality.
If we refactor EventDrivenStateMachine
to be called GlobalEventDrivenStateMachine
(possible different name to be chosen?) that would have all the functionality that the current EventDrivenStateMachine
currently has, sans the Id
field, then inherit GlobalEventDrivenStateMachine
into EventDrivenStateMachine
to provide the Id
field, that would allow for both use-cases.
IRepository
, ICorrelatedRepository
would have a series of methods amended onto it that would allow for this GlobalEventDrivenStateMachine
In the implementation of retrieval/storage of the base EventDrivenStateMachine
, you ensure that the aggregate type is indeed one that requires an id. for the new methods that handle the GlobalEventDrivenStateMachine
, you enforce the aggregate being loaded/stored does not require an id.
Looking at an implementation of an IStreamNameBuilder
, one of two things can happen: 1) a new method can be established on the interface that does not include the Id field.. 2) teach the current GenerateForAggregate
implementation that if the Type IsAssignableTo
EventDrivenStateMachine
, do the current way of creating the stream name... otherwise... create a stream name without an id.
I am unsure of other areas within the system at this time where an EventDrivenStateMachine
/AggregateRoot
is currently used. Depending on where they may be used, additional considerations may need to be taken into account.