Things I still find confusing about Domain Events

Question

a) Assuming we don't use IoC, where should handlers be register? In an Application layer?

b) Perhaps a useless question, but is part of the reason for such a design where handler's Handle method takes Domain Event as an argument because this way we explicitly state which Domain Event is being handled and it also makes code easier to understand if arguments are expressed in terms of a domain model?

c) From

A domain event is a role, and thus should be represented explicitly

What does the author mean by "domain event being a role"?

Thank you

UPDATE:

a)

In IoC terms with would be the composition root of your application.

I don't quite understand what you're tying to convey here?!

b)

Yes, although I don't fully understand your question. What would be the alternative?

I wasn't implying that the design Udi came up with could have an alternative to passing events as arguments, I was just curious whether this design also brings the benefits I mentioned under b)

c)

The concept of a role is based on the idea that a single object can play multiple roles depending on the context.

I haven't read chapters 16 and 17 ( Evans book ), since I doubt I will be involved in large-scale projects anytime soon, but to my knowledge Evans's book doesn't cover this subject ( I'm not implying that this is not important topic, I'm just curious if perhaps I somehow managed to overlook this topic )?

Answer 1

a) Handlers should be registered in the same place that other dependencies such as repositories are registered. In IoC terms with would be the composition root of your application.

b) Yes, although I don't fully understand your question. What would be the alternative?

c) The concept of a role is based on the idea that a single object can play multiple roles depending on the context. Take a look at the author's presentation: Making Roles Explicit.

UPDATE

a) It basically means the place in your application where you configure all dependencies. In a simple console application, with would be somewhere near the start of the Main method. In an ASP.NET application it would be in the method which handles application start. Take a look at this question.

b) Yes, IMO it does bring those benefits, but again note that the handler class itself isn't the interesting part, it can just as well be a lambda.

c) Those parts of the book cover some very important DDD concepts. In fact Evans himself has been somewhat regretful of not putting the strategic aspects of DDD in the beginning. Take a look at the new book in the series Implementing Domain-Driven Design.

As far as roles however, I don't think Evans covers it explicitly in the book. It doesn't have as much to do with DDD as it does with OOP.