0

I'm developing an application using CQRS + ES.

Now I have 2 aggregates which are technically almost exactly the same, only they are different concepts in the domain. Therefore I will separate them into their own aggregates, but I could still use the same events for both aggregates. This would save a lot of work and pointless complexity in the application. Basically they are the same class that has only been separated for DDD sake.

Would there be a problem with this design? The aggregates themselves are responsible for maintaining correct state, so that would not be a problem. The read model does not deal with aggregates anyway, and it doesn't care about the (small) distinction between those 2 aggregates.

Aggregate classes would look similar to the following:

// Aggregate 1
public class Page : AggregateRoot
{
    public Page(string id, ...)
    {
        this.Id = id;

        // Same event for different aggregates.
        ApplyChange(new ContentCreatedEvent(...));
    }

    // etc.
}

// Aggregate 2
public class Asset : AggregateRoot
{
    public Asset(string id, ...)
    {
        this.Id = id;

        // Same event for different aggregates.
        ApplyChange(new ContentCreatedEvent(...));
    }

    // etc.
}
  • Only thing I can think of is whether you have specific handling requirements for whoever receives the event. If not, this works just fine. If you end up needed a separate typed event, well you can create an event factory that will create the more specific event for your type. That helps contain the additional complexity and keeps the same base class. – Berin Loritsch Jun 18 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.