在研究了大量材料和示例之后，我目前正在开始第一次尝试DDD / CQRS / ES系统 .
1）我已经看到了事件源代码示例，其中Aggregates是事件处理程序，并且它们的每个事件的Handle方法都会改变对象实例上的状态（它们为将改变状态的事件实现IHandleEvent <EventType>接口）
2）我还看到了一些例子，其中Aggregates看起来就像是对域进行建模的普通经典实体类 . 另一个事件处理程序类涉及改变状态 .
当然，当从存储库调用重建聚合时，状态由事件处理程序在聚合上进行突变，该存储库调用获取该聚合的所有先前事件，并且当命令处理程序调用聚合上的方法时 . 虽然在后者中我已经看到了在命令处理程序而不是聚合中发布事件的示例，但我确信这是错误的 .
我的问题是方法（1）和（2）之间的利弊是什么
2 回答
接收/处理命令的工作与执行命令的工作不同 . 我采取的方法是有一个处理程序 . 它的工作是接收命令 . 该命令包含AggregateId，然后可以使用它来获取聚合的所有事件 . 然后，它可以通过LoadFromHistory方法将这些事件应用于聚合 . 这使聚合更新并使其准备好接收命令 . 所以我的简短版本是选项2 .
我有一些您认为有用的帖子，第一篇是典型CQRS / ES应用程序流程的概述 . 这不是它们应该如何经常出现的 . 你可以在CQRS – A Step-by-Step Guide to the Flow of a typical Application找到它！
我还有一篇关于如何为CQRS和ES构建聚合根的帖子，如果这有用的话 . 你可以在Aggregate Root – How to Build One for CQRS and Event Sourcing找到它
无论如何，我希望有所帮助 . 所有最好的构建您的CQRS / ES应用程序！
虽然我同意 Codescribler ，但我需要进一步了解细节 . ES是将实体状态表示为事件流（将被存储） . 消息处理程序只是一个服务实现，它将告诉实体该做什么 .
使用ES，实体通过生成一个或多个事件然后将它们应用于自身来实现其更改 . 实体不知道它的变化来自一个命令或事件处理程序（它应该'总是'一个命令处理程序但很好......有时它并不重要），但它通过自己的事件修改状态将被发布通过服务（或事件存储本身） .
但是......在最近的应用程序中，出于实际的原因，我的ES实体直接接受了命令，尽管实体本身不是命令处理程序的实现 . 处理程序只是将命令中继到实体 .
因此，您实际上可以直接使用实体处理消息，但仅作为实现细节，我不建议将实体指定为命令/事件处理程序，因为它违反了关注点分离 .