Event Sourcing - Reconstituting Aggregate from Wrong Event Stream

Question

I am working on a project to help learn DDD and am trying to do CQRS and Event Sourcing. Code is in C#.

For this example, lets say I have 2 aggregates, Customer and Product. My aggregate repository has a get method Get<TAggregate>(Guid id) that loads all events for that ID, creates a blank TAggregate instance, and then replays all the events against that instance. The aggregate ignores events it doesn't know what to do with.

The below will work as expected, each aggregate is reconstituted from its events in the event store

Customer customer = repo.Get<Customer>(customerId);
Product product = repo.Get<Product>(productId);

However, if I try to reconstitute an aggregate from a collection of events from a different aggregate, this currently doesn't throw any errors, but the aggregate instance ignores any events that it doesn't know what to do with so it is left in this "clean" state as if zero events were passed to it.

Customer customer = repo.Get<Customer>(productId);
Product product = repo.Get<Product>(customerId);

I see two ways to solve this problem: - The aggregate itself checks to make sure it is in a valid state prior to allowing any domain opperations. - Event types are explicitly associated with specific aggregate types, events passed to the wrong aggregate type result in an exception.

The aggregate ensures it is in a valid state

Ex:

public class Product : AggregateRoot
{
    private Guid _id;
    private bool _isConstructed;

    public Product(Guid id, ...)
    {
        // enforce domain rules here

        ApplyChange(new ProductAddedEvent(id, ...));
    }

    public void UpdatePrice(decimal newPrice)
    {
        if(!_isConstructed)
            throw new Exception(...);

        // enforce domain rules here

        ApplyChange(new ProductPriceUpdatedEvent(_id, newPrice));
    }

    private void Apply(ProductAddedEvent e)
    {
        _id = e.Id;
        _isConstructed = true;
    }

    private void Apply(ProductPriceUpdatedEvent e)
    {
        ...
    }
}

This could work, but I feel like it can get out of hand very quickly, resulting in bulky, awkward code.

Event types are explicitly associated with specific aggregate types

Similar setup to the above example.

public abstract class Event<TAggregate> where TAggregate : AggregateRoot
{
    public bool IsValidFor(AggregateRoot aggregate)
    {
        return aggregate is TAggregate;
    }
}

public class ProductAddedEvent : Event<Product>
{
    ...
}

public abstract class AggregateRoot
{
    public void Reconstitute(Event[] events)
    {
        foreach(Event event in events)
        {
            if(!event.IsValidFor(this)
                throw new Exception(...);

            ApplyEvent(event);
        }
    }
}

This approach makes the most sense to me. Is there some potential smell here that I am not seeing? Is there something else I'm not considering?

Edit:

One other idea I've had is perhaps that command handler needs to validate the command, querying the read model to ensure that an aggregate of expected type exists with the specified ID. But even if this ends up being the correct approach, is there anything wrong with associating events to specific aggregate types?

Answer 1

Is there something else I'm not considering?

One thing you are not considering is a typesafe interface for your identifiers.

Customer customer = repo.Get<Customer>(productId);
Product product = repo.Get<Product>(customerId);

If this kind of error is what you are worried about, why are you using the same type for your id? Wrap the implementation around two different types, so that the compiler can tell them apart.

The implementation of the repository can pop the guid out of the type when the raw data is needed.

CustomerId customerId = CustomerId.from(...)
ProductId productId = ProductId.from(...)

Customer customer = repo.Get<Customer>(productId); // Type Checker can catch this

Answer 2

What you are trying to prevent is strange because there is no difference between the events that are ignored intentionally and the wrong events.

One solution is to load the events based not only on the Aggregate's ID but also Aggregate's type (or class). For this you need to also store the Aggregate's type in the event stream and use it when you query the Aggregate's events.

Adding the Aggregate type to the event stream opens the door to multiple Aggregates sharing the same ID, which is a good thing, as you can use the same Event store instance for multiple bounded contexts.

Answer 3

Like VoiceOfUnreason said, one aspect of this is the primitive obsession with the IDs. There's basically no place in the code where the productGUID and customerGUID should be in scope at the same time.

Specifically, ProductId.From(customerGuid) wouldn't happen because you wouldn't be calling any ProductId.From() in a context where you have a raw customerGuid.

In addition to that, if you aren't doing lazy domain binding you could add a type to the events, as per Constantin Galbenu's suggestion, but perhaps in a slightly different way:

You are likely to have a certain event type or a certain enum of event types, in any case fewer than the total number of event types for the agregate, that can be the first event ever seen for this aggregate, starting with the banal ProductRegisteredEvent. This way, when you query and get >0 events back but the first event isn't a ProductRegisteredEvent, you can immediately throw without pulling any more events in.

This won't enable you to have multiple separate aggregates with the same ID, but thus allow you to not have any reference to the type in the further events.

Finally, I want to make sure I understand why you have the "Ignore returned but unknown events" policy in place. Are you doing this in projections as opposed to the business logic aggregate? Are the unknown events inconsequential to validating business logic?

Or do you already have different aggregates coexisting on the same ID by having mutually exclusive sets of event types? (Which would mean you already baked the 'aggregateType' property into the event type, in a way.