DDD - Naming events

Hi,

let’s say I have two different contexts: Books and Services. Both contexts contains Order aggregate.
Is it a common practice that same event name exists in different contexts i.e. OrderAccepted? Or the event name should be unique i.e. BookOrderAccepted and ServiceOrderAccepted

Thank

Pavel

Hi!

I don’t know the common practice but I would only make them unique if they appear anywhere together. If they never are at the same place then you don’t need to distinguish them as it would be clear from the context anyway

Hi Pavel, Sam,

I’d say the naming depends on whether both aggregates reside/originate from the same ubiquitous language.
Thus, if the language is identical, then the concepts are identical, which can be reflected in the event naming.

However, from a practical stand point, I’d imagine you’d like to pull them apart.
You could do this either by changing the class name, true.
What you could also do, is have Event interfaces per Aggregate type for example, which you’d implement in the events you’d actually publish.

For example, the Order in Book which dispatches an OrderAcceptedEvent could implement an BookEvent and OrderEvent interface.
Quite similarly, you could do this for the Service context as well.
Doing so keeps the name identical, but makes it specific from a coding perspective which type it is.

This is my two cents to the situation.

Cheers,
Steven

Hello,

I’d give few cents off myself to your question.

When i name events i use pattern [AggregateName]+[Behavior]+ed

The aggregate name part helps me distinguish events that happen within a context of specific aggregate, let it be Book, BookOrder etc. Also here you can see that it helps you design an aggregates, meaning a Book and BookOrder should be different aggregates.
The behavior simply helps me understanding what behavior has happened.

The ‘ed’, past tense part is important, because that’s what the events are, things that happened in the past when we are talking in the ‘receiver’ context.

Given your example of boks I’d imagine events like:

BookCreated
BookOrdered
BookOrderCreated
BookOrderAccepted