thefabric-io / eventsourcing Goto Github PK

Right now, we're tying aggregates to their storage based on the aggregate state type, like so:

// Type returns the type of the aggregate.
func (a *Aggregate[S]) Type() string {
    return a._type
}

This works, but I'm thinking we can do better, especially as we scale up. So, here's what I'm proposing: a StorageNamer interface.

type StorageNamer interface {
    StorageName() string
}

This interface aims to provide a more explicit and customizable way for aggregates to define their corresponding storage entities (like database tables or collections). It could significantly improve the way the library handles storage naming conventions, making it more adaptable to different storage backends and user needs.

The implementation of this interface would be optional. If an aggregate state does not implement StorageNamer, the library would default to using the aggregate state's type as the storage identifier.

First, thank you for sharing this work. Generics seem like a great use case here and I appreciate you sharing your work.

And, I think adding examples will go a long way toward helping others realize value from the work you have shared. I myself am finding some trouble getting my Events to work as I expect. If I could reference an example it would help me ensure I'm setting up my function signatures correctly.

Thank you.

I've noticed a potential area for enhancement in our event application logic that could improve the accuracy and reliability of our domain model's state evolution. Specifically, I propose we adjust the order of operations in the Apply method of our event handling to apply modification and inception recorders after the event has been applied to the aggregate. This change aims to ensure that recorders capture the most up-to-date state of the aggregate.

Current Implementation:

In our current implementation, the Apply method in our event structure performs several operations in the following order:

1. Increment the aggregate version.
2. Append the event to the list of changes.
3. Set the aggregate ID from the event state if applicable.
4. Record inception and modification dates if the event state implements InceptionRecorder or ModificationRecorder.
5. Merge event metadata into aggregate metadata.
6. Apply the state changes from the event to the aggregate.
7. Clone the aggregate and set it on the event.

Here's the relevant code snippet for context:

func (e *Event[S]) Apply(aggregate *Aggregate[S]) {
    // Initial setup and state capture...
    
    if v, ok := e.State().(InceptionRecorder[S]); ok {
        v.RecordInception(&e.occurredAt, aggregate)
    }

    if v, ok := e.State().(ModificationRecorder[S]); ok {
        v.RecordModification(&e.occurredAt, aggregate)
    }
    
    // Applying state changes...
    e.State().Apply(aggregate)

    // Post-application steps...
}

Proposed Change:

I suggest we modify the sequence to apply the event to the aggregate before executing the inception and modification recorders. This adjustment ensures that any transformations to the aggregate's state, including additions of new value objects or other modifications, are fully reflected before we capture their inception or modification timestamps.

func (e *Event[S]) Apply(aggregate *Aggregate[S]) {
    // Initial setup...
    
    // First, apply state changes to ensure the latest state is captured
    e.State().Apply(aggregate)
    
    // Then, record inception and modifications with the updated state
    if v, ok := e.State().(InceptionRecorder[S]); ok {
        v.RecordInception(&e.occurredAt, aggregate)
    }

    if v, ok := e.State().(ModificationRecorder[S]); ok {
        v.RecordModification(&e.occurredAt, aggregate)
    }
    
    // Final steps...
}

Benefits:

• Flexibility: It allows for a more nuanced handling of state changes, particularly for cases where the exact moment of state modification is critical (e.g., when an occurredAt date must be applied to a newly added value object from the aggregate).

I believe this adjustment will provide a more robust foundation for our event sourcing system, capturing state changes more accurately and flexibly. I welcome feedback on this proposal, including any concerns or additional benefits I may not have considered.