使用企业事件流为自主能力域提供动力

免责声明 – 版权归 Rocket Mortgage, LLC [2022 – 2023]。作者 (Nish Nishant) 已获得 Rocket Mortgage 的许可，可以发布本文。本文是 Rocket Mortgage, LLC 的财产，未经授权不得重新分发。

作者说明 – 我为我雇主面向公众的技术博客写了这篇文章，但由于各种原因，该博客已被停用。因为我不想永远失去这些内容，所以我经过明确批准，在此重新发布。因此，请阅读上面的免责声明。

摘要

随着软件系统的数量和复杂性不断增加，它们最终会相互产生意外的依赖。这减缓了科技公司交付的速度。团队被迫延迟交付，因为他们需要等待其他团队完成他们依赖的功能。这种延迟也导致团队无法改进他们的遗留组件。

解决这些挑战的方案包括定义能力域、创建边界 API 并使用企业范围的事件流来实现能力域之间的清晰分离。本文侧重于实现此解决方案所需的​​核心模式，除了作为偶然示例外，不推荐任何特定的工具栈。

能力域

基于能力将技术企业的软件系统定义并映射到域是避免系统间依赖的常见第一步。通常，这些域与技术企业的组织结构相匹配，但这并非必需。每个能力域都负责实现其特定能力的全部功能，理想情况下，域之间不会有任何重叠。

提高域的自主性是能力域的目标之一，这意味着域拥有的系统被视为域内部的系统。因此，构建这些系统的团队可以自由地决定其技术路线图。

这里常见的反模式是内部系统直接与其他域的系统集成。这样做是一种负耦合形式，会抵消定义和映射企业范围能力域的优势。将一个域的功能暴露给另一个域，同时最小化耦合的首选方式是通过域边界。

域边界

域边界是域边缘的公共接口。通常，这些公共接口实现为公共 REST API，并带有已发布的契约。企业内的域需要设定相互期望，即它们只能通过该域的边界 API 与其他域集成。这样做可以解决因直接集成域外内部系统而产生的负耦合问题。

边界 API 也需要向后兼容，并维护一个正式的 API 版本控制系统是一个好习惯。边界 API 本身缺乏内部域系统所享有的自主性，但这是避免阻碍路线图的依赖所需付出的很小的代价。

企业事件流

事件流是连续的事件流，细分为命名的事件主题。企业事件流是一个共享的事件流，所有能力域都在其中发布和接收消息。

事件流通常构建在数据流平台之上，例如 Confluent Kafka、Amazon Kinesis 或 Azure Event Hubs。无论您选择哪个供应商，它们都拥有一套标准的、核心的功能来流式传输事件消息，并且都针对高可扩展性、并发性、弹性和性能进行了优化。然而，比您的供应商选择更关键的是标准化事件模式、能力所有者以及控制对这些事件的访问。

结合域和事件流

图 1 - 位于企业事件流周围的域

一旦结合实施，能力域和企业事件流可以帮助企业在域之间实现高度的独立性。图 1 显示了多个域（X、Y、Z 和 W）；这些域之间没有直接耦合。它们仅通过企业事件流进行集成。还有多个消费者（A、B、C 和 D），这些消费者要么与企业事件流集成，要么与域 API 集成，但绝不会直接与域内的组件集成，例如域 X 内部的应用 API。

此模式有两个基本原则

1. 域仅通过域边界 API（通常称为域 API）直接与其他域集成。
2. 域通过企业事件流生成和消费企业事件。

域生成的企业事件及其域 API 是暴露的唯一公共契约。它们是其域中必须遵循企业标准并向后兼容的唯一方面。其他所有支持该域能力的内容都属于域内部，这使得域所有者在选择实现语言、库、容器技术、云资源偏好和软件标准方面拥有高度的自由。

例如，一个域可能在 Microsoft Azure 上使用 .NET 和 C#，因为他们的团队成员精通这些技术。即使企业中的其他部分使用 Amazon Web Services 上的 Java，这两个域也会发布标准化的事件到企业事件流，并公开一个公共 REST API，这对于它们选择的技术栈是无关紧要的。

事件负载模式

图 2 - 常见负载模式

不同的企业会选择最适合其业务需求的方法。通常，企业事件有三种类型的负载模式。图 2 说明了三个不同的消费者：A、B 和 C，它们各自使用一种负载模式。消费者 A 使用轻量级模式，消费者 B 使用完整负载模式，而消费者 C 使用混合方法。

轻量级事件

对于轻量级事件，事件负载通常是单个标识符或 URI（统一资源标识符）。消费者接收事件，然后调用域 API 以检索与该事件相关数据的当前状态。轻量级事件的好处是节省了数据量，因为事件非常小，并且您无需担心事件排序，因为消费系统始终从源域检索最新的数据状态。轻量级事件的缺点是消费者必须进行 API 调用才能检索所需的数据。

完整负载

在完整负载中，事件负载是事件数据在固定时间点的完整状态快照。消费系统在接收事件时拥有所需的所有信息。这些系统节省了调用域 API 的麻烦。完整负载的缺点是处理事件的顺序很重要，这是一个已解决的问题，因为所有流行的供应商都支持保证的消息排序。

混合方法

在混合方法中，事件负载是事件状态的部分数据集。负载包括源标识符和 URI，以及事件状态的子集。这使得一些消费者可以确定他们是否需要从域 API 检索更多数据，同时允许其他消费者基于事件负载中的数据子集状态进行操作。许多人认为混合方法是两全其美。

没有完美的方法可以做到这一点，如果一个企业选择使用多种这些方法来适应特定需求，这表明该企业很成熟。

结论

高度独立且交付快速的技术公司使用企业事件流和对多个能力域的编目。它们将其与遵循标准的域所有者相结合，公司通过能力域进步的叠加效应而发展。