CODEWITHSUNDEEP
domain-driven-design
mgonzalezbaile
mgonzalezbaile

Reputation: 1086

How many listeners in a Bounded Context can be subscribed to a specific domain event?

I have a doubt regarding the best strategy for how many listeners can be subscribed to a specific domain event.

Say that we have a domain event called UserWasCreated being published when a new user is created in the Bounded Context A. Say that we have another Bounded Context B subscribed to that event in which we have to do many tasks such as: sending an email, persisting certain information of the user and pushing the user info to an external service (i.e.a CRM).

My question is, how many listeners should I have for that event within the same Bounded Context?

I've seen IDDD book from Vernon having just one listener per event like this UserWasCreatedListener. But that listener has just one specific responsibility while in my example there are different tasks involved.

Would it make sense having one listener per event-task? So following the example we would have:

UserWasCreated_NotifyByEmailListener
UserWasCreated_NotifyCrmListener
UserWasCreated_PersistUserListener

If it does make sense, how would you name these listeners? Is there any scalability problem because of creating too many listeners?

Upvotes: 2

Views: 117

Answers (1)

Eben Roux
Eben Roux

Reputation: 13256

The short answer directly related to how many listeners (subscribers) there can be for an event: 0 to N

I like to distinguish between the following types of events:

  • Domain
  • Event Sourcing
  • Messaging (System)

The reason is that they have different meanings and would, in many cases, carry different data.

Back to your question. You are describing a process. A process is typically started by some command or, as in your case, event. A process may be driven in on of two ways:

  • Orchestration
  • Choreography

When messages are choreographed they are very reactive. The means that one event leads to another. In your case you could have:

  • UserCreatedEvent -> PersistUserHandler (subscriber) -> UserPersistedEvent
  • UserPersistedEvent -> CrmListener (subscriber) -> CrmUserCreatedEvent
  • CrmUserCreatedEvent -> EMailNotifier (subscriber) -> UserNotifiedEvent

These work OK if it is a rather simple, sequential, flow. When you need user intervention, such as reviewing items, or parallel processing things tend to get hairy.

Orchestraion, on the other hand, makes use of a process manager that keeps the state of the process and interacts with the various atomic services.

In your case you could have a UserRegistrationProcess that would be instantiated when required. In your case perhaps on the user creation. Another approach is to kick off the process and have it include the user creation. Your UserRegistrationProcess would be the subscriber to the various events. But instead of the various listeners reacting to arbitrary events they only service the relevant commands.

  • Start Process
  • Process sends CreatedUserCommand to the UserEndpoint (BC)
  • Process receives UserCreatedEvent from the UserEndpoint (BC)
  • Process sends CreateCrmUserCommand to the CrmEndpoint (BC)
  • Process receives CrmUserCreatedEvent from the CrmEndpoint (BC)
  • Process sends the SendEMailCommand to the EMailEndpoint (infrastructure) Process receives theEMailSentEvent` fromt the EMailEndpoint (infrastructure)
  • Terminate Process

In this way the process layer becomes a bounded context in its own right.

I prefer orchestration since you always have a view on the progress of an process.

Upvotes: 2

Related Questions