What is the purpose of using DomainEvents?

[Synergia503]

Hello!
Thanks for your good job with that project. It helps me a lot!
However, I don't understand the purpose of DomainEvents in your Domain. There are no dispatchers for them, take as an example:

• MemberSetAsAttendeeDomainEvent (only three references - no dispatcher)
• NewMeetingHostSetDomainEvent (four references - no dispatcher)
• etc...
  I thought once, that every event should have its dispatcher to dispatch changes that are carried by this event. What am I missing here? Why only events between modules are somehow handled?
  Take this: NewMeetingHostSetDomainEvent -> it is called in SetAsHost() method in MeetingAttendee Entity. This event is created and added to DomainEvents collection for this Entity and nothing more happens. I am aware of GetAllDomainEventsmethod in DomainEventsAccessor and DispatchEventsAsync in DomainEventsDispatcher and await _mediator.Publish(domainEvent) in the foreach loop. But... there is no Subscriber to this particular NewMeetingHostSetDomainEvent? Or I cannot find it? If there is some Subscriber for this event, where is it? If there isn't, what's the purpose of these events?

[AndreiGanichev]

Hi, @Synergia503.
I guess you missed Domain Event Notification conception. It's a way to handle a domain event in a separate transaction. Check these blog posts:

1. How to publish and handle Domain Events
2. Handling Domain Events: Missing Part

[Synergia503]

Hi @AndreiGanichev ,
thank you very much for your response. I've read carefully these articles and now I understand more. But still, there is one this unclear for me - why do we have/need such events like NewMeetingHostSetDomainEvent if these events are not handled anywhere? Just for future needs? Does not this violate YAGNI?

[AndreiGanichev]

I see it this way. What is Domain event?

A domain event is a full-fledged part of the domain model, a representation of something that happened in the domain. Ignore irrelevant domain activity while making explicit the events that the domain experts want to track or be notified of, or which are associated with state changes in the other model objects. Eric Evans. “Domain-Driven Design Reference"

So domain events are first class citizens in DDD, they are not just mechanism to implement Publish-Subscribe pattern. Domain events model real world. Just like in the real world, events occur regardless of whether someone is watching or not, domain events don't depend on the presence of their handlers.

Look again at the quotation above:

making explicit the events ... which are associated with state changes in the other model objects

So domain events are part of observable behavior of an Aggregate(result of it's state changes) which is checked in unit-tests. Moreover in high-encapsulated model domain events can be the only observable behavior (for event from your question check CompanyName.MyMeetings.Modules.Meetings.Domain.UnitTests.Meetings.MeetingRolesTests for successful test case). And this behavior doesn't depend on presence of event handlers.

Domain events are handled by Application layer. Application layer depends on Domain layer and not vice versa.

[Synergia503]

Okay, I understand that

domain events don't depend on the presence of their handlers, and they model the real world.

But software is not the real world, why bother with the code, which does not have side effects? Does not this look like too much overhead?

And this behavior doesn't depend on the presence of event handlers.

Okay, this is obvious to me, however, this adds additional code which has to be understood by the team, to be maintained, to be tested, to be executed in the runtime, etc... And there is no or almost any advantage of this approach (or I don't see). We only see that some event is thrown, which models the real world (SetAsHost -> NewMeetingHostSetDomainEvent), but... in the properly isolated domain, in properly isolated aggregate root and properly named method we can see the same. What else can do SetAsHost method on MeetingAttendee Entity, if not setting Role to Host? Is throwing an event about that such an important thing, even when we don't react to this event?

[kgrzybek]

Hi @Synergia503!

1. As @AndreiGanichev DomainEvent is a first-class citizen and building-block in DDD tactical patterns set (and in EventStorming workshop) and in my opinion it is good to express them in the code even for some events there are no subscribes. In my opinion it greatly improves readability of your Domain Model (but this is of course subjective matter). I don't see a lot of overhead with publishing an event (as you described understanding, maintaining?, testing?, executing?).
2. Sometimes, you will need to publish more than one type of domain event after one action. Sometimes there will be some conditional (publish OrderPlaced or publish OrderWithDiscountPlaced). Then you need to test this and as @AndreiGanichev mentioned too, events are the only way to observe state change. In that case you will need to add them even they will don't have subscribers.
3. When you have all events published, it is trivial to implement Audit trail/log. This is missing in that project (I have this in roadmap). It is a matter only to add one subscriber to all Domain Events, serialize domain event and store this data in database.
4. Migration to Event Sourcing will be easier (in ES you need DomainEvents always, this is how you store entities state).

[Synergia503]

Hi,
long time, no response. I wanted to try "your" approach and incorporate DomainEvents (almost) everywhere and it seems indeed good. However, the efforts needed for convincing people to this approach are not negligible, not everyone in the company likes this approach. I cited your arguments and they didn't work, at least not for all teammates.
For 2. and 4. I cannot say anything now.

But I have a question for 3.
I would like to display some of the events in the UI, like "Something with Id: ### created", "Something with Id: ### was edited by ###". "Something was deleted at ###". I have EF Core 5 with SQL Server behind.
How would you implement this Audit/Trail log? In the separate table in SQL Server, in separate DB, for example, NoSQL?
With separate DB, when to save serialized events? After committing changes to the SQL Server?
If I store events in a separate DB (let's say MongoDB) then I imagine I have to span in one transaction committing changes into SQL Server and in MongoDB. Saving in Mongo can fail, so I would have to roll back changes from SQL Server. Is that right?
Thus this approach only with SQL Server and a separate table seems better for me now, what would you say?