0

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 )?

user437291
  • 4,561
  • 7
  • 37
  • 53

1 Answers1

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.

Community
  • 1
  • 1
eulerfx
  • 36,769
  • 7
  • 61
  • 83
  • I've been thinking of purchasing Implementing Domain-Driven Design, so could you give your opinion on how useful this book may be in the hands of someone with no knowledge of SaaS, Scrum, SOA and CQRS ( I asked the author this same question, but got no reply - I guess he didn't want to take the blame :D )? – user437291 Feb 14 '13 at 20:27
  • "Those parts of the book cover some very important DDD concepts" You mean those strategic aspect are also important when designing small DDD apps? – user437291 Feb 14 '13 at 20:37
  • 1
    They are even for small apps. The most important thing to be aware of the potential of multiple bounded contexts. This can have significant impact on your model. And the IDDD book is a great resource. I may be biased because the author is an acquaintance of mine and I helped review the book, but it is certainly worth checking out. Knowledge of SaaS, Scrum, SOA and CQRS isn't required. In fact, those topics are covered in the book and how they relate to DDD. – eulerfx Feb 14 '13 at 20:54