#111 - EventCatalog Revolutionizes Governance in Event-Driven Architectures | ft. David Boyne
51:00 Share

嗨，欢迎回到另一期《真实世界无服务器》节目。今天，我们邀请到了 David Boyne，他是 Winglang 的开发者布道师，也是 Event Catalog 的创建者。嘿，伙计，很高兴你来到这里。嘿，Ian。是的，非常感谢你邀请我。是的，我们最近才见面，实际上。是的，很高兴来到这里。我一直是这个节目的粉丝，看过你的节目。所以能够来到这里和你交谈真是太棒了。所以相当……

我很感激。太棒了。是的，在曼彻斯特见到你，以及在曼彻斯特的 AWS Compsom（曼彻斯特 AWS 大会）上见到你真是太好了。很高兴听到你对事件驱动架构的看法，因为我知道在你 AWS 工作期间，甚至在那之前，这都是你的拿手好戏。是的，没错。是的，说实话，我只是自然而然地进入了这个领域。实际上，在那之前，我是 AWS 的客户，然后我……

构建碰巧构建的是，你知道，sns sqs 所有这些好东西，然后 event bridge 推出，我爱上了它，剩下的就是历史了，我只是最终为 aws 工作并宣传这些东西，但我只是，是的，我喜欢事件驱动架构，所以……而且自从自然而然地，我没有……

我很想了解更多信息，也希望你能谈谈 Event Catalog，以及你对它未来发展方向的设想。但我认为，为了解释 Event Catalog 存在的背景，你能谈谈你在事件驱动架构方面看到的一些常见挑战吗？当然。

我们还有多长时间？不，但是有很多。有很多。从业务角度、技术角度以及各种角度来看，都有很多。我记得我第一次开始，你知道，只是开始行动，对吧，只是实现一些东西。所以我记得我第一次开始的时候，EventBridge 刚刚推出，在事件总线上触发事件是多么容易，对吧，尤其是在今天，对吧？

进入的门槛越来越低。所以我经常看到的一个问题，我自己也遇到过，就是这种先实现后思考的心态。我们直接跳进去，开始在我们的架构中触发事件。我们的客户正在下订单，人们正在订阅，所有这些事情。让我们只触发事件并在这里处理它。

而没有必要考虑任何后果，就像，是的，我们可以有一个 Lambda 函数，或者我们可以在这里做一些事情。所以，你知道……

有很多。这里有很多内容。从设计到实现，都有很多复杂性。通过这些，你得到了诸如事件重复、幂等性等等之类的东西。然后随着我们的发展，你知道，在更高的层次上，就像，那么事件设计本身呢？架构演进策略呢？

以及标准和治理。我的意思是，治理，我们可能会稍后讨论，但这就是 Event Catalog 所处的位置。但这在这个领域是一个巨大的、巨大的问题。

但是，我不知道你是否想从任何一个开始，否则我可以继续谈论，当然，也许让我们看看整个开发工作流程，从好的方面开始，你正在考虑构建事件架构，以及你首先需要考虑的一些事情，我认为就像你说的那样，很多人直接进入并开始发送事件，只是后来才意识到，嗯，我们真的没有办法……

思考这一点，架构，确保人们不会通过更改契约来破坏其他下游系统。我们如何对它们进行版本控制？我们如何捕获有关事件的信息，以便我们能够以某种方式重播、编目和可视化它们，例如需要知道……

一些更简单的事情，我们使用什么作为事件 ID？我们是否有某种统一的格式，或者每个人都只是使用从例如 EventBridge 获取的任何源事件 ID？当我们离开 EventBridge 并转到其他地方时会发生什么？然后我们该怎么办？我们还如何映射来自不同服务和领域设计的事件、契约以及所有这些其他事情？让我从一开始就说。你认为……

你首先应该做对的一些事情是什么？我认为你谈到了你的架构和一些版本控制之类的东西。我认为，是的，我认为从顶部开始。我认为最简单的方法是开始，正如我所说，尤其是在今天。但我只是强烈建议我与之交谈的人们停下来思考一分钟。与架构师朋友一样，正如你所知，我们有分布式系统。我们有在不同边界和系统之间进行通信的消息，并且……

你必须真正考虑这些边界在哪里？你也在那里提到了领域驱动设计。我认为领域驱动设计和事件架构之间存在巨大的关联。因为我们的系统的边界在哪里？如果我们使用消息，不一定是事件，而是消息在这些系统之间进行通信，

这些消息是什么样的？谁拥有消息和下游消费者等等……有很多东西可以帮助，我推荐查看或开始使用的一些东西是事件风暴或事件建模，非常流行的东西，但你实际上可以与业务所有者交谈，与人交谈，这对于技术人员来说很有趣，但实际上是与……

并实际识别架构中的一些事件。因为事件本身，存在不同级别的事件。我们可以有一个低级别的私有实现事件。也许我们在同一个团队，并且在同一个边界内。我们正在创建一个订单系统，因此我们可以创建一个订单、一个已下达的事件或其他什么。

但这与我们在边界之间、在我刚才谈到的这些系统之间使用的事件完全不同。但是作为一名开发人员，或者正在收听节目的观众，我认为你只会考虑这么多事件，但也有业务事件，例如领域事件。我认为最好从创建一个整体图景开始，我们的系统实际上在做什么？

我们有 10 个微服务，20 个。

一开始使用事件架构的东西，你可能会认为这不是问题。团队里只有我和 Jan，我们是一家初创公司等等。但是，你知道，你希望它能够发展壮大。你希望团队能够发展壮大。你希望发展成为一个大型组织，你知道，如果事情进展顺利的话。如果没有考虑我们提到的架构、事件、向前和向后兼容性、文档或验证或测试，事情就会变得非常混乱，对吧？

所以这些是你想要考虑的事情，甚至像重试之类的事情。有很多事情需要考虑，但同样也有很多好处。有些人可能会在听后想，哇，好吧，如果你只是告诉我所有不好的事情，我为什么要这样做？

但是这种方法、这种演进式架构方法、我们可以触发事件并在未来使用它们，有很多好处，我喜欢这一点。我以前在团队中实施过这些东西，这是一种我以前在做基于 REST 的东西、API 东西的 20 多年中从未见过的敏捷性。不要误会我的意思，我们的架构会有这个，但我认为关键在于不同的思维方式。这种心态必须是……

我们必须深思熟虑，而不仅仅是直接使用 EventBridge、SNS 或 RabbitMQ、Kafka 或其他东西。因为你会看到价值。你会看到最初的价值，你可能会从这里获得多巴胺的刺激，事情看起来很棒，然后突然之间，事情就不好了。我们必须重试事件。我们必须重播事件。现在，我们如何处理？我们的 Lambda 函数是什么副作用？

或者我们的代码现在正在执行，因为我们已经重播了事件。哦，我们没有考虑过这一点。这些是这种架构类型带来的后果。但是，如果你了解其中一些事情，就进入这种架构类型，我认为这在以后真的可以帮助你，你知道，只是让自己做好准备，让自己取得成功。如果你不这样做，

如果你没有做好准备，我不知道，我觉得在这个行业中有一个共同的主题，那就是……会出现一些常见的问题，并且……我相信人们可能会……责怪架构类型和技术，而我不一定知道，它更多的是一种心态，很多都是心态的改变以及你如何处理它……

是的，我认为这是许多团队拓扑学家经常谈论的事情，即组织是社会技术组织，你不能仅仅依靠技术来解决你所有的问题。你的组织，对吧，你的……

社会方面与技术方面同样重要。如果两者不一致，你只会制造更多问题。所以最终，事情可能无法正常工作。这并不是因为技术本身无法正常工作，而是因为你组织自己的方式。这并不是与技术一起工作，而是与技术的工作方式背道而驰。我经常看到试图采用无服务器实践的人遇到这种情况。

他们仍然到处都有这种严格的看门人制度。因此，我认为，再次……

团队拓扑学经常谈论流程，拥有快速的流程。但是，如果你到处都有门，这意味着你所有这些功能团队都试图快速移动。他们可以快速准备好他们的代码，但很快每个人都会撞到同一堵墙。看门人，基础设施团队，他们基本上掌握着你 AWS 帐户和环境的钥匙，每个人都被挡在那里。因此，作为……

如果你有阻塞组织中所有流程的事情，那么你将看不到任何价值，就像你所说的事件驱动架构一样，是的，你可以，你可以，你可以拥有这种非常灵活的能力，并构建可以……你知道……

随着时间的推移轻松演变的系统，而不会遇到这种契约、API 契约的问题等等。不同的服务可以独立演变。但是，如果你不考虑如何……这将如何与你的组织一起工作，以及它将如何与你的实践一起工作，因为你编写代码的方式，你编写测试的方式，很多都必须改变并适应你正在做的事情，你正在使用的技术。同样适用于服务，我认为，你知道，

我过去做的事情，我现在做的事情有所不同，因为无服务器的工作方式与在服务器上运行东西以及运行现代提升应用程序的方式不同。所以我需要改变我的开发方式。很多人都不想这样做。他们想做的正是他们以前做过的事情，只是让它适应他们正在使用的新的范例。这只是试图扩大规模。

将方形木桩塞进圆孔里，它会在各处遇到问题。那么在这种情况下，Event Catalog 如何发挥作用？你试图用 Event Catalog 解决哪些具体问题？

是的，当然。是的。事件驱动架构的一个大问题是，正如我提到的那样，一开始一切都很顺利。随着规模的扩大，你会有更多团队触发事件。常见的问题会出现，例如，事件在哪里？例如，我怎么知道组织中存在哪些事件？你知道，你正在谈论，其中一些团队规模很大。其中一些企业用户只是规模巨大。

规模巨大。然后同样，就像我即将进行重大更改一样。谁会受到影响？所以现在我们正在谈论架构演进。我们正在谈论可发现性。我们正在谈论治理和标准。这是一个奇怪的问题，尤其是在事件架构中，因为在这个领域我们似乎落后了。所以……

例如，如果我们负责为组织构建 API，我很确定我们会很好地掌握如何做到这一点，因为人们已经做了 15 年、20 年、30 年或更长时间了。开放式 API 规范以及所有这些东西，并且存在用于执行此操作的治理和策略。但我感觉 EDA 领域落后了，我与之交谈的人越多，

并且交谈，出现的问题就越多。老实说，很多都在这个治理方面。所以 Event Catalog 解决了这个问题。这才是它的愿景。它是与技术无关的。无论你使用 Rabbit、Kafka、SNS、SQS、EventBridge 或其他什么，都没关系。

它是可发现性，为事件架构的企业带来可发现性，并允许你的团队基本上说，我有这个事件，谁在使用这个事件？谁在产生这个事件？这个事件的架构是什么？我是否即将破坏某人？谁拥有这个事件？哪个团队拥有这个事件？甚至更进一步，就像，我有一个服务。

这项服务触发 10 个事件并使用 4 个事件。好的，它触发了哪些 10 个事件？它触发了哪些版本的事件？它是否仍在监听这个其他团队正在监听的事件的旧版本？当你开始绘制这张图时，你实际上可以开始……

我不知道，只是跳过许多人正在陷入的这个巨大的治理陷阱。所以我在两年前开始创建 VEG 目录，只是一个副项目，就像我认为这个想法很酷，看看其他人是否真的，看看它是否解决了那里的任何问题。是的，两年后，越来越多的人正在使用这个开源项目。对于那些正在收听的人来说，这是一个开源项目。我们有 Discord 成员。随时加入。

但在过去的两年里，吸引力越来越大。事实上，我离开 AWS 的原因实际上是为了将更多时间投入到 Event Catalog 上，因为它现在处于需要更多努力、更多时间、更多管理问题出现等等的阶段。但是在这个治理领域仍然有巨大的价值。而且……

而且，它似乎不存在。有一些东西，例如云事件就是其中之一，这是一个允许你以标准方式记录事件的规范，这非常非常有趣。因为即使是你如何设计事件也是一个雷区，它可能是一个雷区。

因此，云事件规范已经推出。我今年毕业了，现在我们可以开始为我们的事件使用标准规范了。它不会强制执行，你知道，你如何做某些事情。

但它告诉我们这里有一些你可能想要遵循的特定标准。最棒的是，一旦我们有了标准，我们就可以开始围绕这些东西集成和编写工具。因此，如果我们快进到未来，如果云事件被采用，它已经在许多地方被采用，当我们想要与流或其他业务事件集成时，如果我们的代理或技术知道如何与云事件集成，我们可以开始获得该价值。

我认为只是，我认为这个 EDA 世界仍在探索这些标准和规范以及这些，你知道，我们似乎是，我不知道，对我来说，感觉就像，我们似乎落后于 API 领域 10 多年，在这个领域还有很多事情要做。有巨大的价值可以获得。另一个值得提及的规范是异步 API。这是一个相对较新的规范。

但这允许你记录通道和消息，以及我的服务做什么以及所有这些东西。它只是允许，你知道，一旦你有了这些规范，我们就可以开始编写工具、代码生成、跨所有这些东西的模型。

所以，是的，我有点，我在这里喋喋不休，但是 Event Catalog 的帮助是，我对这个项目的愿景只是将可发现性和治理带到你的混乱中。目前有很多人从四面八方涌现出来说，嘿，我们遇到了这个问题。感谢 Event Catalog。它正在帮助他们。但我仍然觉得在这个项目中，我只是完成了 100 步中的第一步。所以，是的。

好的。你能实际演示一下吗？你有什么可以展示你拥有的环境的东西吗？你可以向人们展示我们可以做什么吗？因为显然你提到了不同的，我认为，你记录事件的方式的规范，嗯，事件的架构，但你也有，你知道，其他可以……

在较小程度上做类似的事情。例如 EventBridge 有自己的架构注册表，但这只是一个简单的注册表。它没有执行 Event Catalog 在跟踪订阅者方面可以执行的许多事情，并且可能，你知道，因为你知道这种关系，你可以做更多的事情。

正是如此，是的。所以我正在共享我的屏幕，但我认为人们也会收听，所以我将尝试解释我正在做什么。但是，如果你访问 eventcatalog.dev，你将看到此处的网站。这将为你提供正在发生的事情和正在做的事情的概述。但是 Event Catalog 基本上是由 markdown 文件生成的，好吗？所以如果你可以编写 markdown 文件，我希望大多数人都可以做到，

那么你可以使用 Event Catalog，它使用名为 MDX 的东西，这是一个自定义组件库，基本上是增强版的 markdown，它允许我们执行自定义组件以及各种事情。所以如果你想开始，请到这里来，但我将快速向你展示你得到的结果，以便你可以看到演示。

所以你听到的一切都是由 Markdown 生成的。目前它是一个静态网站。它是一个静态网站，这有其优缺点。这样做的好处是它可以在任何地方托管。它可以托管在你的机器上。它可以托管在 S3 上。它可以几乎在任何地方托管。它带有 Docker 文件。它带有搜索以及各种奇奇怪怪的功能。

但整个想法是它是事件驱动架构的文档工具。因此，它从领域驱动设计和事件驱动架构中汲取了很多经验，并将这些结合起来，希望能提供一些价值。你在这里看到的 Event Catalog 中的一切都是可选的，具有域的概念。所以再次，这是域，回到领域驱动设计，我们有一个有界上下文。

但是假设我们正在创建一个系统，我们有这个订单域。我们可以开始为人们记录它。我们可以开始拥有谁拥有这个域，哪些服务属于这个域。我们有可视化表示和图表，我们可以点击事物并拖动事物来实际查看正在发生的事情。体育运动，例如 Mermaid，

图表和流程，各种各样的东西。流程基本上是……

如果你认为像端到端编排一样，对吧？所以你的产品所有者或你的业务可能会说，好的，当用户取消订阅我们的系统时会发生什么？现在，实际上，可能是什么，五个事件，六个事件，两三个不同的服务，正在发送电子邮件，所有这些东西。通常情况下，如果幸运的话，这会在某个 Wiki 中记录下来，或者你只是阅读代码。

但是流程是 Event Catalog 中另一种记录方法，好的，端到端，这个特定功能在做什么，以便我可以进入并深入研究。

所以这就是那里的想法，但是你在这里看到的每一页都是 markdown，你可以根据需要添加或删除尽可能多的内容，但整个想法也是你可以开始链接事物，你知道，域的概念有服务，所以如果我进入一个服务，这是我们的库存服务，所以这个服务本身可以是 api 网关 lambda 无论你使用什么，你知道 dynamo db 这是服务，正如我所说，Event Catalog 是……

与技术无关，并不关心你使用什么。但是我们可以从这里看到，

我们可以看到库存服务，这就是它所做的。它有一个更改日志。Event Catalog 支持更改日志。例如，当你更改架构时，当你更改服务时，它实际上可以为这些资源、这些实体编写更改日志。例如，Jan，你可能会加入公司，并且你的任务是处理库存服务，你可能想知道有关库存服务的某些历史记录，为什么事件中的这些特定字段会发生变化。

我们可以使用 Event Catalog 来做到这一点。我们可以说，好的，这是版本 A，这是版本 B。这个字段由于这个特定原因而发生了变化。现在，这些上下文都没有被捕获。对吧？

对。许多公司根本没有捕获此上下文。因此，当人们加入和离开以及我们的系统发展时，问题是，价值是，你知道，为什么它会发展？我们为什么从这个变成这个？我们需要做什么才能将其提升到下一个版本？

正如我所说，Event Catalog 附带一些基本功能和一些组件，允许你执行屏幕上显示的操作，例如步骤组件。我可以在这里复制代码，也许这是一个将事件使用此特定架构触发到 EventBridge 的代码片段等等。

所以我想，等等，在我们继续之前，你提到所有这些都是 markdown。那么，这意味着作为 Event Catalog 的用户，我必须编写 markdown 来生成这些页面，并且这里的所有说明都必须由团队中的某人手动维护吗？正确。所以有一些选择。所以第一个是，是的，所以所有这些都是 markdown。所以你必须制作，有人必须维护它。

现在，如果你想自动化它，还有另外两个选项。所以 Event Catalog 实际上也有一个 SDK。所以现在你可以使用这些函数来基本上说，好的，我想添加一个事件。我想，我不知道，添加一个服务，删除一个服务。我想对事件进行版本控制。

现在，这里有趣的事情是，好的，所以现在如果我们在 Event Catalog 中有一个 SDK，我们可以开始自动化一些事情。现在，我想自动化什么？好的，假设你在某个地方有一个 Kafka 集群，并且你想从中读取主题。好的，所以我可以读取主题。现在我想记录这些主题。我可以开始使用这个 SDK 来构建 Event Catalog。事实上，我可以开始编写生成的脚本……

每次我的 Event Catalog 想要构建时，这就会引导我进入下一件事，那就是不同的集成，并且……

所以 Event Catalog 有这个生成器的概念，它就像一个预构建的脚本，我想。但是这些生成器会获取特定的资源，例如异步 API、开放式 API，以及几周前推出的 EventBridge。它将转到源，即你的文件或架构注册表，提取它需要的信息，然后为你记录到 Event Catalog 中。

为什么这很酷？因为它允许你与架构注册表或你的异步 KPI 文件保持同步，但同样允许你在其上添加其他上下文。所以让我快速解释一下。

Amazon EventBridge 有一个架构注册表，它有一个架构发现功能。所以你要做的是，你可以在 EventBridge 上启用此功能，进入和离开总线的事件将自动为我们记录。它们将自动在架构注册表中获得架构。现在，不幸的是，这还不够，因为我们有一个架构。我们可以执行代码模型等等。但是……

上下文丢失了。这是什么架构？它属于什么？服务是什么？是什么，所有这些东西，它都消失了。所以你只能使用 Event Catalog 和此示例中的 EventBridge，我们可以为多个架构注册表提取架构。就像我们可以提取信息，我们可以生成我们的目录数据一样。

有趣的是，我们可以在 markdown 中使用附加上下文来向我们的事件添加附加上下文。所以让我再次解释一下，我们提取信息。此信息存储在目录中，然后我们可以使用其他 markdown 上下文来填充该信息。那么这对你的团队意味着什么？

是好的，我们正在使用 EventBridge，我们位于 EventBridge 中，我们有多个事件总线，无论发生了什么……而且……这是一个 Event Catalog，它会告诉你所有不同的事件，现在开箱即用你不会得到太多，你会得到一个架构，仅此而已……

但是，如果你的开发人员或你的团队想要记录该特定事件，这是什么订单已下达事件或订阅已取消事件？这是什么意思？我该如何触发它？架构是什么？架构为什么改变了？你可以开始添加此上下文。然后从可发现性的角度来看，你拥有这个不断从注册表中生成的东西，并且你拥有团队添加的其他上下文。

我不会过多介绍，但是这里有很多事情。你甚至可以，我只是在屏幕上显示，你可以通过源、前缀、后缀、详细信息类型将特定事件映射到目录中。所以你可以说，好的，我的注册表中有大约一千个事件，但我只想映射……

由于我们组织中使用了myapp.orders这样的约定，因此我们将这些事件与myapp.orders的来源关联起来，我将把它映射到这个，我不知道，例如订单服务。因此，您可以开始尝试并混合匹配，无论您的事件约定是什么，您都可以开始将这些事件映射到您的域和服务中。同样，这只是一个例子。

目前有很多用户使用async API来生成他们的目录。在这个例子中，你有三个服务，三个团队。每个团队都记录了他们的服务。他们使用async API来记录该服务的message。在这个例子中，message可以是事件、查询或命令。事件目录将进入并提取所有这些

来自所有不同团队的spec文件，并在最后给你一些东西，它会说，好的，这是你的可发现性工具，你的团队可以像event bridge一样在文件中添加不同的上下文，同样，这一切都是自动化的，从文件中读取，如果你想，你可以添加手动的内容，或者你可以使用sdk来，是的，你知道，做你想做的事情

是的，有很多事情要做。对于实际的流程，我认为这很有趣，因为我们在事件驱动架构领域经常听到一句话是，作为一个发布者，你应该知道消费者是谁。这就是事件与命令的概念。但是作为该系统的开发者，你确实需要知道谁在监听你的事件，或者至少是否有人在监听你的事件。

因此，如果要进行更改，您可能需要提前与他们沟通等等。流程是一种向您展示谁是事件订阅者的方式。我猜这是手动维护的，还是有某种方法可以让订阅者自动让事件目录知道，“嘿，我的服务现在正在订阅此事件”，以便它会增强和更新可视化效果。

是的，没错。目前，流程本身，这就是流程。目前的流程是手动的。流程有点像这种YAML格式。但是目前在SDK上有一个开放的功能来添加对这个的支持。现在，为什么这很酷呢？因为我可以使用SDK来创建流程、编辑流程、更改流程等等。

流程是一种不同的思维方式。如果我是一个消费者，我现在正在消费一个特定的事件，这是否意味着我改变了流程？流程是端到端的业务流程。

谁不知道，我不知道，在这种情况下。但在服务案例中，你会看到，你肯定会自动看到一个消费者已经加入，并且消费者现在，正如你在这里看到的，消费者现在正在消费这个特定的事件或这个消息。我实际上可以深入到不同的事件、不同的服务、不同的领域。我们可以点击这些，然后放大。

放大，缩小，看看发生了什么。流程也是一样的。所以，我不知道，这回答了你的问题吗？是的，有点，因为我试图在脑子里比较它，并把它与PostNL使用他们自定义构建的事件代理所采取的一些更运行时的方案进行比较，该代理位于

我猜是发布者和订阅者之间，所以他们知道，当订阅者订阅一个事件时，所以他们能够生成这个，你知道，这个依赖图，而这个图实际上非常有用，我不知道他们现在是否正在使用它，这是我在实现业务工作流时发现的事情之一

即使各个组件本身可能不需要知道谁在监听，但作为一个试图实现这个业务工作流的业务所有者，我该如何确保所有合适的人都在监听正确的事件，并且在其中没有中断

你正在使用的不同过滤器规则。我无法告诉你，有多少次我遇到过这样的问题：上游发誓他们发送事件一切正常，但下游却没有任何事件。因此，整个业务工作流都中断了。这是因为，好的，合同中的一些小的变化，或者过滤器规则设置不正确，导致事件从未在下游触发。那么，我该如何将其可视化？

在顶层。这就是让我更倾向于使用step functions进行业务工作流编排方法的原因，因为，你知道，我无法设计它。而且没有，没有留下很多空间，我想，嗯，

那种错误或可视化在你可以看到好的，那是工作流，那就是将会发生的事情，至于不使用事件，更多的是好的，每个人都在做他们的事情。但是如果我们，你知道，正确地关联编排一切，我们将获得正确的行为。所以现在和你在一起，我想带来这种可视化和这种

他们理解工作流并将其可视化的能力，在事件驱动架构中。我认为这就是我试图在工作流可视化方面获得的东西。

是的，我完全同意。我记得Step Functions，超级强大，只是和某人一起坐下来，并可视化正在发生的事情等等。事件目录是一个有趣的东西。它最初是作为一个静态站点生成器开始的，能够以不同的方式带来可发现性。

我目前正在与许多用户和社区讨论下一步是什么样的。我认为事件目录，如果事件目录知道模式、生产者和消费者，想想你可以在其之上构建的工具。例如，它可以是验证，可以是代码模型或其他任何东西。或者在你的情况下，它可能是，我可以使用这个工具做更多运行时的事情吗？我可以做更多……

事情来帮助那里，或者我的服务可以使用事件目录来获取最新的模式，我们可以根据它进行验证，以及各种事情。我想过的一个功能，我过去与人们谈论过的是

你知道，如果我作为一个消费者正在消费一个事件，这是一回事。但你只对事件的特定字段感兴趣。有一种粒度消费，我想。这有点回到Postal定律，他说，在你做什么方面要保守，在你期望从别人那里得到什么方面要自由。

我认为这具有巨大的价值。我想象一个工具，我想象事件目录是这样的，好的，我订阅了你的事件，Jan，我将要，我只对这一个或两个字段感兴趣。其余的我并不关心。但是如果这些字段中的任何一个即将更改，我可以得到通知吗？如果该字段消失，我可以得到通知吗？如果它从int变成了string，我可以得到通知吗？这个通知将去哪里？这会去Slack吗？我可以重新运行我的测试或我的系统等等吗？

据我所知，目前没有任何东西可以解决这个问题。但是当我与事件目录用户提出这个问题时，这是一个非常有趣的事情。我认为事件目录，如果它被用作核心治理工具，我认为可以在其之上添加大量的运行时和自动化以及额外的价值。

是的，绝对的。整个契约测试部分也将很有趣，因为我知道我们有PACT，PACT在技术上也可以用于事件驱动架构的契约测试。但是作为一个空间，它在如何将其用于事件驱动架构的测试而不是API方面，并没有很好的文档记录或很好的理解。

这是我最近与PostNL的Luke以及Lego的Sarah多次讨论过的事情，他们采取的不同方法，PostNL的事实是他们有一个代理，发布者和订阅者必须注册他们的订阅和他们的模式，

首先到代理。因此，代理有时间和空间来这样说：“好的，你正在将一个字段从int更改为string。这是一个重大更改，所以我们不允许这样做。”因为就像我说的，你想要对你期望的东西严格。因此，代理在那里是为了保护订阅者免受破坏性合同更改的影响。但与此同时，

你知道，如果现在没有人订阅这个事件，为什么我不允许更改模式呢？而且，你知道，当你知道事实上有人在监听该事件时，你想强制执行它。因此，这可能会对他们造成重大更改。

但也存在行为变化。例如，好的，这是一个字符串，很好。但是不能保证在运行时，有人会发送空字符串而不是正确的ID或其他什么。错误仍然可能发生。它们仍然可能是破坏性的。因此，你仍然可以做其他事情。

你想能够捕捉到，这就是我希望像pact和消费者驱动的契约这样的东西能够填补这个空白的地方，尽管现在还不清楚这到底是如何工作的，我一直在试图弄清楚pact如何用于EDA，并且在那里没有取得多大成功，Lego所采取的方法，我认为你今天看了Sarah在Compsom上的演讲吗？我确实看了，今天早上看的，好的

是的，所以他们有一个非常有趣的方法，他们采用了一种更轻量级的PACT版本，他们只是将模式发布到NPM，然后消费者针对该模式编写测试。它没有PACT的强制执行元素，你谈到的是当上游更改模式时，可以向下游发送某种通知，因为在这种方法中，

下游订阅者负责从发布者那里提取最新版本的模式包，运行他们的测试。但在大型企业中，由于团队重组、人员流失等等，会有很多系统。该系统没有被积极地使用。那么，当您进行更改时，如何确保这些系统正在生产中运行，

现在没有人实际使用它们，但您仍然不想破坏它们，对吧？那么，你如何确保，你如何提供治理，强制执行合同的元素？我觉得这就是事件目录，位于中间，更多的是设计时工具，可以在测试周围的特定空间中提供很多价值，作为整体治理的一部分。

完全正确，是的。正如你暗示的那样，我认为这是一个雷区，我想，在那里。

有了这些东西。并且有一些策略，有一些其他策略你可以强制执行，但这更多的是一个治理问题。例如，好的，我们的模式演变策略是什么？我们是向后兼容的，还是向前兼容的？如果你在考虑它本身，你就在一个很好的空间，但大多数人没有。大多数人只是对这些东西进行YOLO，这就是头痛出现的地方。但我认为你是完全正确的。我认为这是愿景。事件目录的愿景之一确实是

正是如此。我认为它有可能解决其中的一些问题，因为它知道消费者是谁。它是技术无关的。它实际上是模式无关的。它支持Avro、JSON，任何你想要使用的。因此，如果它有这种插件方式或自动化方式，我们可以将其中一些规则定义为用户，并且你可以收到

即将发生的更改的通知，你知道，你可以在测试、暂存或生产中拥有一个目录，那么，你知道，我认为它肯定是一个附加值，因为正如你所说，今天我们有pact，我看到了Sarah的模式内容，这很酷，它仍然感觉非常，嗯，你知道，我们我们可以在这个领域改进很多，我认为，是的，绝对可以做到

是的，所以我非常高兴你全职从事这项工作，因为我认为这绝对是一个正在寻找，正在呼吁解决方案的空间。理想情况下，你可以付费使用，而不是必须自己托管任何东西。是的，是的，是的。是的，这仍然是早期阶段。正如我所说，事件目录仍然处于早期阶段。

该项目本身是开源的，它是免费的，仍然试图使事情可持续发展，因此正在探索各种方法，例如托管目录、插件双许可证，我还不知道它是什么样子，但是有一些问题需要解决，所以希望，你知道，希望我们能够解决它们，并在某些时候解决其余的问题

是的。是的。我的意思是，整个，是的，我非常喜欢DDD领域一直在做的事情。你知道，我们甚至没有讨论过的一件事是反腐败层以及DDD为你提供的其他所有模式。是的。

嗯，这个，你知道，模式和观察，我想，如果你这样称呼它的话，DDD领域为你提供了，我非常渴望看到更多的人采用这些实践，就像我说的，第一步就是意识到它们，并考虑它们，而不是仅仅盲目地进入，哦，只是，你知道，只是全力以赴，这工作得很好，然后突然，我的天哪，这太糟糕了，发生了什么，是的，发生了什么，然后

是的。然后说实话，你知道，我们以前都见过，你最终会进行大规模重写，人们会离开，我不知道，但你是完全正确的。只是意识到，你之前提到了无服务器思维方式，对吧？我认为本质上有一个EDA，我的EDA思维方式。嗯，

这并不是一种典型的做事方式。任何分布式系统都不是。只是理解其中的一些陷阱，例如，好的，你知道，正如你提到的，域驱动设计中的边界上下文映射，了解它们是什么，不要一定要全部使用它们。

但是会有你消费事件的时候，我想知道这个事件模型是否在我的领域中，是否需要将其更改为我们团队理解的内容？好的。你知道，我们在这里谈论的是普遍语言，一些标准的东西，但最简单的方法就是消费和继续。就像，哇，我现在在我的通知电子邮件系统中到处都有这个订单模型，发生了什么，

这只是关注点分离。这是一个有趣的问题，因为当我们在一个代码库、一个单体中时，多年来人们一直在做solid和dry的事情。你会看到所有这些漂亮的模型、模式和东西。但是一旦我们将它分解成这个分布式世界，我认为相同的原则适用，但我们只需要意识到……

你知道，这些边界。默认情况下，不幸的是，这些都没有。这取决于你去解决。如果你不这样做，我保证你至少在几年内会陷入困境。

是的，绝对的。我看到很多人遇到了这种问题的描述。甚至像我们多次谈论的域一样简单的事情，域事件，对于许多不理解这一点的人来说，域事件甚至意味着什么。甚至边界上下文也是另一个很好的例子。边界上下文的实际定义是在其中你有一组普遍语言，一种统一的理解。

但这并不是大多数人使用它的方式。我也犯了这个错误。很多时候，我只是有点懒，用边界上下文来表示一个系统。你只是错误地假设一个系统是一个域，一组团队所有权，一组语言。但通常情况下，边界上下文远大于一个系统。它可能是一个包含许多系统的整个业务领域等等。所以

所以即使我们有时谈论它的方式，它也可能很棘手。这可能是困难的。是的，在这个特定领域有很多混乱。

另一个领域，我想，即使它已经相当成熟，但仍然有点，你知道，感觉有点像狂野西部，那就是基础设施即代码。所以，你知道，你已经使用Wing Lang一段时间了。你能给我们做一个高级的介绍吗？你知道，为什么我们需要像Wing Lang这样的东西？为什么，你知道，为什么CDK或CloudFormation或Terraform不够？是的。

是的，当然。你知道，我在几个月前，也就是6月份加入了Wing Lang，当我还在AWS的时候，我一直在关注他们在做什么。我联系了Alad和Shai，那里的创始人，说，你知道，你需要帮助吗？我加入了他们，参与了这段旅程。但Wing Lang非常有趣，就像我以前从未见过的事情一样，对吧？合并了，你

你知道，这是一种全新的编程语言，它结合了你的应用程序，你的基础设施即代码。例如，为什么我不能在我的代码中，为什么我不能声明一个bucket？

并且我有对bucket的权限或其他什么，像Wing会为你处理所有这些。但是我们有预先飞行、飞行中和飞行后的概念，我认为这就是魔法所在。但在预先飞行中，这是配置代码，对吧？我有一个bucket，我可以在这个特定部分对bucket执行特定操作，对吧？这些事情就像，我试图想一些，

也许授予一些权限或向bucket添加一些属性或其他什么，对吧？但在飞行中，这是运行时代码了。我们实际上可以开始与bucket交互。所以我可以向bucket添加一个特定的对象等等。但思维方式非常有趣。思维方式是，一旦你理解了这一点，就会觉得，好的，我只需要专注于……

只需要专注于特定的一段逻辑或应用程序代码。例如，Wing会理解在你的飞行中，在你的运行时中，你需要这个函数需要某些权限，它会为你处理。我不需要担心这些事情。

它是，是的，它非常非常有趣，如果你们感兴趣的话，推荐你们去看看他们网站上的例子，去Discord，但是如果你对，你知道，我觉得我们需要下一步，你知道，CDK等等，以及，你如何简化云，我认为，我认为，我认为这是一个进步，对于

当然，在那里工作的人，我与他们一起工作的人，他们都是超级聪明、友善的人，所以是的，如果你感兴趣，来吧，或者问我任何问题，我会很乐意帮忙，但是，你知道，那里有一些学习曲线，它是一种全新的编程语言，就像，你知道，Rust，或者如果你要去或者其他什么，它是一个全新的东西，所以是的

而对于编程语言来说，最吸引我的是你实际上可以……你……

我猜你的游乐场是你自己定义的游乐场，因为它本身就是一种新的编程语言。所以这让我花了一段时间才弄明白，但我们可以开始做一些本地模拟的事情。所以Wing实际上支持本地模拟。所以如果我正在构建一个应用程序，比如API或bucket或函数或容器或其他什么，

我可以实际运行一个名为wing it的命令，我实际上可以在我的机器上运行它，因为我们有不同平台的概念等等。我不知道。这是一个完整的，这是一个完整的演讲。但是，你知道，如果你对云的编程语言感兴趣，它不与AWS绑定，你知道，有Azure和，

还有GCP，甚至自定义平台，这非常有趣。所以如果你正在构建，比如如果你有，假设你是一个企业，我们以一种特定的方式进行函数处理，我们以一种特定的方式进行处理，你可以实际创建你自己的平台，然后为你的工程师提供针对这些平台部署的代码。所以是的，它很棒。它很疯狂。它很酷。

对。是的。所以我想它让我想起了Gregor Hopp在离开AWS之前谈论的事情。他说这是架构即代码的宏伟愿景。所以，你知道，不仅仅是因为大多数人使用CDK的方式是他们只使用一级、二级结构。

充其量，而真正的力量在于三级结构。在正确的手中，你可能能够实现这种宏伟的愿景，即使用代码描述你的架构的自定义，也许几乎是特定于业务的语言。

Greg谈论了他认为人们应该如何使用CDK，以及我实际看到人们如何使用CDK，这是一个非常不同的事情。所以对我来说，这就是，好的，Wing Lang具有这种优势，因为它是一种专门设计的编程语言。

我的意思是CDK可能有机会使用结构，但因为它必须与每个人一起工作，我想，所以你必须支持那些低级结构，一级和二级等等，这会失去你应该从通用语言中获得的很多表达能力，就像CDK试图做的那样。所以我很

我对Wing Lang正在做的事情充满希望。而且我，你知道，我一直在关注你们正在做的事情。我希望将来有一天能在这里得到回报，也许，你知道，就像我说的，做一个关于Wing Lang的完整演讲，以及，呃，它如何，呃，它将如何彻底改变，呃，我看到。而且，呃，

但是，是的，David，非常感谢你今天抽出时间与我们交谈。很高兴听到你对事件驱动架构的见解。我希望你能继续改进事件目录，并期待看到你接下来会做什么。是的，谢谢，Jan。是的，非常感谢你邀请我。这太棒了，太棒了。

是的。我想今年我不会在re:Invent上见到你，因为你将忙于你的事件目录。但我希望以后能见到你。一路顺风，伙计。是的，当然。总是。干杯，伙计。干杯，各位。回头见。回头见。

这就是另一集Real World Serverless的全部内容。要访问节目笔记，请访问realworldserverless.com。如果你想学习如何构建可用于生产的无服务器应用程序，请查看我在productionreadyserverless.com上的即将推出的课程。下次见。