Event Store deals with Domain events or representation of domain events

Question

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.

Answer 1

Most discussions about storing events in an event store borrow language from the Eric Evans blue book. Chapter 6 describes the life cycle of entities within the domain model, and in particular the notion of an abstraction "the repository" that provides to the application the illusion that the entities can all be retrieved from an in memory collection.

So the repository is an abstraction, and the actual implementation details of loading and storing events lives behind it.

If you are going to insist upon "layers", then you are right -- it won't be in the domain model at all, the repository is purely an application/infrastructure concern.

These days, you are more likely to hear "ports and adapters" terminology -- the repository is an abstraction of the connection to the database/event store.

Or should the domain events be serializable/deserializable?

Most implementations tend to store events using a message serialization - JSON, Avro, Protocol Buffers, and so on. Some sort of immutable data structure; there are some cases where you must want a bespoke schema for storing events, but by and large a commodity solution is the right idea here.

That representation may or may not match what you use in memory. In theory, you could just use the JSON byte array directly, but it's more likely that you'll parse it once to build a DOM or some bespoke value type.

In some places they call them Integration Events.

Careful -- the common distinction made between "domain events" and "integration events" is a different meaning than the one you are using here.

Is that correct?

Pretty much. I think the easiest way to keep track of it is this; you are supposed to be able to change your domain model from one release to the next. Events are one kind of message from the old model to the new model -- events need to be stable over longer periods of time than the domain model does.

do you have a good link that talks about these concerns?

Greg Young: Versioning in an Event Sourced System