事件通知
当一个系统发送事件消息，通知其他系统它已在自己的域中进行了更改时，会发生事件通知。 事件通知的一个重要因素是源系统对响应不太感兴趣。 源系统通常不希望响应。 或者，如果有源系统感兴趣的响应，这也是间接的。 发送事件的逻辑流与响应事件的特定响应的逻辑流之间存在明确的隔离。
事件通知非常好，因为它实现了低级耦合，并且很容易设置。 但是，如果有逻辑流实际上正在运行各种事件通知，这将是一个问题。 这个问题是因为在任何程序文本中都不明确，所以很难看到这样的流程。 通常，检测这个过程的唯一方法是监视实时系统。 这样的话，很难去调试和修改这样的过程。 危险的是，通过使用事件通知，可以更容易实现良好的系统去耦，而不会意识到正在失去大规模的流程控制。 因此，今后几年会出现麻烦。 这种模式仍然非常有用，但必须注意这里的陷阱。
陷阱的一个简单示例是事件被用作被动攻击命令。 虽然源系统希望收件人执行操作，并且必须使用命令消息来表明其意图，但是如果将消息设置为事件方法，则会出现问题。
一个事件不需要携带很多数据，通常只有一些身份信息和返回发送方的连接，所以可以查到更多的信息。 收件人知道事情发生了变化，可能会得到关于变化本质的最小信息，并向发件人提出决定下一步该怎么做的要求。
事件状态转移
当您希望更新系统的客户端，但不需要向源系统通知更多工作时，就会出现此模型。 当客户更改详细信息(如地址)时，客户管理系统可能会触发包含已更改数据详细信息的事件。 然后，接收方可以使用最新数据更新客户数据的副本，而无需为了将来的工作与源客户端系统进行通信。
该模型的明显缺点是存在大量的数据和副本。 但是在大容量存储时代，这个问题也不大。 即使客户的系统出现问题，接收系统也能正常工作，因此更加灵活。 访问客户信息不需要远程呼叫，从而降低了延迟。 不必担心客户系统的负载是否满足所有消费者系统的咨询。 但是，由于接收方必须保持所有状态，所以接收方确实会变得复杂。 简单的方法是在必要时通知发送方获取更多的信息。
事件源
事件的来源主要是，无论我们什么时候去改变系统的状态，我们都会把它作为一个事件来记录状态的变化。 此外，我确信将来的任何时候都可以通过重新处理事件来重建系统的状态。 事件存储实际上是主要的来源，系统的状态完全来自事件存储。 对于程序员来说，最好的例子是版本控制系统。 的所有提交日志都是事件存储，源树的工作副本处于此系统的状态。
案源介绍了很多议题，这里不一一介绍，但我想强调常见的误解。 请考虑一下事件处理不需要异步完成，而是更新本地git版本库的情况。 它是一个完整的同步操作，就像更新subversion这样的集中式版本控制系统。 当然，拥有所有这些承诺，就能做出各种有趣的行动。 git是一个很好的例子，但提交核心功能基本上是一个简单的行为。
另一个常见的错误是，使用事件源系统的所有用户都必须了解并访问事件日志以确定有用的数据。 但是，对事件日志的认识可能很有限。 我用一个编辑器写这个。 我们认为源树中的所有提交都是未知的，并且磁盘上只有一个文件。 事件源系统的大部分处理可以基于有用的工作副本。 只有真正需要事件日志中信息的元素才能处理副本。 如果这个效果好的话，可以有多个不同模式的工作副本； 但是，通常在域处理和派生工作副本之间应该有明确的区分。
通常，在使用事件日志时，拍摄工作副本的快照很有用，因此不需要每次需要工作副本时都从头开始处理所有事件。 实际上这里有二元性，事件日志可以看作变更列表或状态列表。 我们可以从另一个派生一个。 版本控制系统通常在事件日志中混合使用快照和增量，以获得最佳性能。
事件源有许多有趣的优点，在考虑版本控制系统的价值时很容易想到。 事件日志提供了强大的审核功能。 会计事务处理是帐户馀额的事件来源。 可以通过在特定点重新播放事件日志来重新创建历史记录状态。 我们还可以在重播时注入假设事件来探索可替代的历史。 事件源允许非永久工作副本，如图像记忆。
案源也确实有一些问题。 如果结果取决于与外部系统的交互，重播事件将出现问题。 我们必须弄清楚如何处理随时间变化的事件模式。 许多人已经注意到事件处理给APP应用带来了许多复杂性。 但是，我想知道这是否是因为生成工作副本的组件与执行域处理的组件之间存在分离不良。
CQRS
指令查询责任隔离(CQRS )概念意味着信息的读取和写入具有独立的数据结构。 严格说来，CQRS与事件无关。 因为如果没有事件，则可以在设计中使用CQRS。 但是，通常人们会把CQRS和以前的模式结合起来，所以会出现在峰会上。
CQRS的意义在于，在复杂的领域中各个模型处理读写过于复杂，可以通过分离模型来简化。 无奈的金毛在访问模式不同的情况下(例如泛读少书)，这特别有魅力。 但是，使用CQRS的好处必须与具有单独模型的附加复杂性相平衡。 我发现很多同事对CQRS的使用非常警惕，经常被滥用。
理解这些模型热衷于样品收集
本的软件植物学家，我发现这是一个棘手的领域。核心问题是混淆了不同的模式。在一个项目中，有能力和经验丰富的项目经理告诉我，事件溯源是一团糟 - 任何改动都需要双倍时间来更新读写模型。就在这句话中，我可以发现事件溯源和CQRS之间可能存在些混淆 - 那么我怎样才能找出哪个是dtdfy？ 该项目的技术主管声称主要问题是大量的异步通信，当然它是一个已知的复杂性助推器，但并不是一个必须参与事件溯源或CQRS的部分。此外，我们必须要注意所有这些模式在正确的地方都很棒，而在错误的领域上则很糟糕。但是当我们混淆模式时，很难弄清楚正确的领域是什么。