Event Store deals with Domain events or representation of domain events

by iberodev   Last Updated August 03, 2018 21:05 PM

I am starting a new DDD architecture and I have a dilemma with Domain Events and the way they're retrieved and stored in an EventStore database.

First of all, should the EventStore live in the Domain layer or in the application layer? At the moment it makes more sense to me to have it in the application layer since the domain shouldn't really care about "storing" events, just consuming them.

Secondly, let's imagine that a domain event has a property that is an abstract class or interface, something that cannot be serialized or deserialized without knowing the concrete implementation. Is this allowed? Or should the domain events be serializable/deserializable?

If, as I imagine, this is allowed because domain events are meaningful within our business logic and should not care about being transferred, it means that our domain events should be mapped to a representation Event DTOs that can be transferred to other systems (e.g: placed in a bus) or stored (e.g: persisted in an event store). In some places they call them Integration Events. I call them Event DTOs

That leaves the Application layer as the only place where the EventStore could live. Therefore the event store is in charge of storing/retrieving Event DTOs (that are perfectly serializable/deserializable).

Is that correct? And most important, do you have a good link that talks about these concerns? I am really struggling to decide in which layer things leave.

Related Questions

How to create new aggregate root in CQRS?

Updated February 21, 2017 13:05 PM

CQRS - Passing aggregate root as argument

Updated February 25, 2017 23:05 PM

Event Sourcing and cross Aggregate validation

Updated January 10, 2018 23:05 PM

Map commands to value objects in CQRS

Updated July 21, 2018 14:05 PM