4

Domain events are well known in DDD, which can be published in Aggregate Roots or in Domain Services. My question here is, Can domain events be published in application services/use cases?

For example, simplifying. I have an application service called UseCaseA, which performs various operations calling some aggregate roots. If I want to raise an event when this use case ends, could I publish the UseCaseAFinished event within this application service? Is it a domain event or should it be called an application event? Does application event terminology exist in DDD?

Thanks in advance.

Giorgos Ntymenos
  • 361
  • 2
  • 13
Mr. Mars
  • 762
  • 1
  • 9
  • 39

2 Answers2

3

Can domain events be published in application services/use cases?

Usually not: domain information belongs to the domain model, not to the application.

Now, it is normal for the business to be interested in the progress/termination of a process. But that's just a clue that suggests that the process itself is something that should also be modeled in the domain.

"Application events" would be more likely dedicated to application concerns: think "observability".

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • So, events could be launched from the application services to be able to perform observability tasks, for example monitoring or logging, right? And in the case of wanting to send an email when the use case ends? Should it be done at the domain layer using a domain event or could an event thrown by the application service be used? – Mr. Mars May 28 '20 at 06:30
3

I think you should look this from another perspective. Let me explain.

Instead of raising an event as an outcome of your UseCaseA to handle your side effects, such as sending an email the event you want to raise should still be a Domain Event like you described.

Then at the time of handling this specific Domain Event you could raise an "Application event" (I'd call them Integration Events) which would then handle the side effect of sending an email, doing monitoring, logging..

This integration event can span multiple BCs, services and even applications.

Step-by-step flow example:

  1. Start executing UseCaseA
  2. Perform operations on entities, change state etc.
  3. Raise a domain event from the domain
  4. Dispatch the domain event just before the end of executing UseCaseA
  5. Catch the domain event in one or more Domain Event Handlers
  6. In one of those handlers, raise an Integration Event to handle "application wide" side-effects
  7. Handle integration event in Integration Event Handler and send emails, do logging, notify monitoring etc.

The integration event can be dispatched multiple ways, but usually via some sort of event bus.

Joonas Lindholm
  • 146
  • 4
  • Hi, if there more than one domain operations as part of a use case, which domain event handler should be used to raise Integration Event – Dipendu Paul Mar 24 '21 at 11:33
  • This is usually highly situational and I'd say: It depends. What I have done in the past is that at if some point I don't quite have a clear understanding of which particular event inside a use case should result in an integration event to be raised, I'll create a separate domain event handler whose only purpose is to raise an integration event. Later on, as things begin to clear up, I'll refactor (remove, join, etc. handlers) – Joonas Lindholm Mar 24 '21 at 12:20