a）假设我们不使用IoC，处理程序应该注册在哪里？在应用程序层？
中 b）也许是一个无用的问题，但这是设计的一部分原因，其中处理程序的 Handle方法将域事件作为参数因为这样我们明确说明正在处理哪个域事件，如果参数用表示，它也使代码更容易理解域模型？
c）From
域事件是一个角色，因此应该明确表示
作者的意思是“域名事件是一个角色”？
谢谢
更新：
a）
在IoC术语中，将是您的应用程序的组合根。
我不太明白你在这里要传达什么？！
b）
是的，虽然我不完全理解你的问题。会是什么 替代方案？
我并不是说Udi想出的设计可以替代传递事件作为参数，我只是好奇这个设计是否也带来了好处我在 b）
下提到过c）
角色的概念基于单个对象的概念 根据具体情况发挥多种作用。
我还没有读过第16章和第17章（埃文斯的书），因为我怀疑我很快就会参与大型项目，但据我所知，埃文斯的书并没有涵盖这个主题（我并不是在暗示）这不是一个重要的话题，我只是好奇我是否设法忽略了这个话题？）
答案 0 :(得分：1)
a）处理程序应在注册其他依赖项（如存储库）的相同位置注册。在IoC术语中，将是应用程序的组合根。
b）是的，虽然我不完全理解你的问题。会有什么替代方案？
c）角色的概念基于单个对象可以根据上下文扮演多个角色的想法。看一下作者的演讲：Making Roles Explicit。
<强>更新
a）它基本上是指应用程序中配置所有依赖项的位置。在一个简单的控制台应用程序中，将在Main方法的开头附近。在ASP.NET应用程序中，它将在处理应用程序启动的方法中。看看this question。
b）是的，IMO它确实带来了这些好处，但再次注意到处理程序类本身不是有趣的部分，它也可以是一个lambda。
c）本书的这些部分涵盖了一些非常重要的DDD概念。实际上埃文斯本人has been somewhat regretful没有把DDD的战略方面放在一开始。看一下Implementing Domain-Driven Design系列中的新书。
至于角色，我不认为埃文斯在书中明确地涵盖了它。它与DDD的关系不如OOP那么多。