主要观点：

• 事件驱动架构存在诸多不确定性等，通常认为其对 REST API 不相关，但不必完全采用。
• 现代应用多有基于 HTTP 的 API 遵循 REST 原则，而事件驱动架构基于系统发布已发生的事件。
• 对于终端用户交互，纯事件驱动不是正确方式，用户需告知系统做某事。
• 大型应用中，多个团队开发的服务间交互方式多样，可通过事件驱动架构进行事件协作。
• 事件驱动架构可去除运行时耦合，服务可独立处理请求，提高系统可用性。
• 类似于函数式编程的“函数核心，命令外壳”模式，在服务间保持“纯”和事件驱动。
• 服务间通信应多用事件，查询和命令用于前端及非事件驱动的系统。

关键信息：

• 介绍了事件驱动架构与传统请求响应架构的区别。
• 提及函数式编程中的“函数核心，命令外壳”模式及在事件驱动架构中的应用。
• 强调在系统外壳可采用请求响应通信，核心部分采用事件驱动。

重要细节：

• 以简单服务和请求响应服务通信图为例说明传统架构。
• 以事件驱动服务通信图说明事件驱动架构的优势。
• 指出服务可用性在不同架构下的计算方式。
• 以“命令、查询、事件”模式说明服务间通信类型。