为什么命令和事件分别代表？
强调事件的架构中的命令和事件有什么区别？ 我能看到的唯一区别是命令通常由系统外部的angular色来源/调用，而事件似乎是由系统中的处理程序和其他代码提供的。 但是，在我看到的许多示例应用程序中，它们具有不同（但function相似）的接口。
命令可以被拒绝。
事件已经发生。
这可能是最重要的原因。 在事件驱动的体系结构中，提出的事件代表已发生的事情是毫无疑问的。
现在，因为命令是我们想要发生的事情，事件是发生的事情，所以当我们命名这些事情时，我们应该使用不同的动词。 这推动了单独的表示。
我可以看到，命令通常由系统之外的参与者来源/调用，而事件似乎是由系统中的处理程序和其他代码提供的
这是他们分开表示的另一个原因。 概念清晰。
命令和事件都是消息。 但实际上它们是分开的概念，应该明确地对概念进行build模。
通过一些例子，尤其是格雷格年轻的演示文稿（ http://www.youtube.com/watch?v=JHGkaShoyNs ），我得出的结论是，命令是多余的。 他们只是你用户的事件，他们按了那个button。 您应该以与其他事件完全相同的方式存储这些数据，因为这是数据，您不知道是否要在未来的视图中使用它。 您的用户确实添加了，然后从篮子中删除该项目，或者至less尝试。 您稍后可能想使用此信息在稍后的date提醒用户。
而且，除了这里公开的所有答案之外，事件处理程序也可以在接收到事件发生的通知之后触发命令。
例如，在创build客户之后，您还需要初始化某些帐户值等。在您的客户AR将事件添加到EventDispatcher并由CustomerCreatedEventHandler对象接收后，此处理程序可以触发一个命令的分派，将执行任何你需要的，等等
另外还有DomainEvents和ApplicationEvents。 差别仅仅是概念上的。 您希望首先发送您的所有域事件（其中一些可能会产生应用程序事件）。 这是什么意思？
发生CustomerCreatedEvent后初始化帐户是一个DOMAIN事件。 向客户发送电子邮件通知是一个应用程序事件。
你不应该混淆他们的原因是很清楚的。 如果您的SMTP服务器暂时closures，这并不意味着您的DOMAIN OPERATION应该受此影响。 您仍然希望保持聚合的未损坏状态。
我通常将事件添加到我的分派器在聚合根级别。 这个事件是DomainEvents或者ApplicationEvents。 可以是，也可以是其中的许多。 一旦我的命令处理程序完成，我回到执行Command处理程序的代码堆栈中，然后检查我的Dispatcher并派发任何其他的DomainEvent。 如果所有这一切都成功了，那我就结束交易。
如果我有任何应用程序事件，这是发送它们的时间。 发送电子邮件不一定需要打开到数据库的连接，也不需要打开事务范围。
我偏离了原来的一个问题，但是了解事件在概念上是如何被区别对待也是很重要的。
那么你有萨加斯….但这是WAYYYYclosures这个问题的范围:)
是否有意义？
他们代表孤立，因为他们代表非常不同的事情。 正如@奎斯坦所说，命令是可以被拒绝的信息，而成功则会产生一个事件。 命令和事件是Dtos，它们是消息，在创build和实体时它们往往看起来非常相似，但是从那以后，不一定。
如果你担心重复使用，那么你可以使用命令和事件作为你的（messge）有效载荷的信封
class CreateSomethingCommand { public int CommandId {get; set;} public SomethingEnvelope {get; set;} } 然而，我想知道的是你为什么问：你是否有太多的命令/事件？
除了上面提到的概念上的差异之外，我认为还有另一个与常见实现有关的差异：
事件通常在需要轮询事件队列的后台循环中处理。 任何对此事件感兴趣的方通常可以注册由于事件队列处理而被调用的callback。 所以一个事件可能是一对多的 。
命令可能不需要以这种方式进行处理。 命令的发起者通常可以访问命令的预期执行者。 这可以是，例如，以执行者的消息队列的forms。 因此，命令是针对单个实体的 。
我认为Quentin-santin的答案是：他们：
将请求封装为对象，从而允许您使用不同的请求参数化客户端，排队或logging请求，并支持可撤销操作。
来源 。
