通过手动轮询从RESTAPI更改的实体来建模事件流

我的任务是创建一个事件流，在此过程中，我有一个自动轮询器（设置为10分钟间隔）来检索过去10分钟内更改的所有实体

现在，业务逻辑规定我们只在实体中的特定字段更改时创建新的更新事件。由于我们没有特定字段更改的粒度（我们所知道的只是某些更改），因此我必须创建某种区分方法，以执行以下操作：

获取上一个实体状态

将此先前状态与最新状态（即差异）进行比较

如果至少有一个业务逻辑确定为重要的字段，则创建更新事件

如果已创建更新事件，请将以前的实体状态替换为最新的实体状态

考虑到这个体系结构问题，是否有一个已知的模式或模式集，或者如何构建这种类型的系统的指导原则？

请查看和，以及的范例

请注意，这些是处理状态更改（或事件）的相当通用的方法。实现取决于您使用的编程语言和操作环境。您应该寻找现有的框架和库，例如（跨平台）或（Java）

---

关于概念之间关系的有趣讨论。

此问题的规范解决方案与之相反：系统不应在做出更改后检测更改，而应首先生成更改事件。否则，API不允许存储新的实体版本；相反，它应该只允许应用更改。从系统设计的角度来看，反向工作（在已经进行更改之后检测更改）会创建一个更复杂的系统，因为它包含更多的步骤

此方法最常见的实现是，这也非常适合。这两者通常放在一起。正确地实现事件源可能是一项困难的任务，在没有充分理由的情况下当然不应该使用它（尽管您的用例听起来确实像这样）。根据更改发生的位置，您可以考虑使用有助于更改跟踪的框架（例如在UI层中）。

---

我理解，可能需要将此修改添加到已经围绕存储实体版本而设计的系统中。在这种情况下，一个可能的解决方案是在两个世界之间设置一个隔离级别：系统中的一个层将实体版本转换为变更流。例如，保留现有接口，但将其实现替换为基于事件的接口；在系统中尽早创建事件，而不是混合使用这两种方法

---

希望这有意义。

嗨，谢谢你的回答。您能否进一步扩展隔离层解决方案？为了提供进一步的上下文，当从外部模块化API轮询创建和更新的实体时，我尝试创建事件（基于业务规则），这是我到数据所在的关系数据库的唯一接口。这本身就是一个现成的应用程序，所以我不能修改它，实现必须在我使用API之后进行。我必须使用哪些选项来保持此

的简单性

？即，如果我需要根据实体中的特定更改创建事件（例如，状态字段从“待定”更改为“已接受”），除了必须存储所有实体外，我是否还有其他选项来根据更改创建事件，当API只告诉我实体整体已经更新时。哦，我的回答涉及到存储数据本身的应用程序。如果你在it之外工作，我不认为上述方法很容易适用。轮询选项有一个很大的缺点-不存在正确的轮询频率：太频繁会在两个应用程序上产生大量负载，太不频繁会错过中间更改。如果您主持这个应用程序，也许您可以考虑监听底层的DB提交日志，或者拦截其他地方的更改（例如：收听HTTP请求），前提是您的许可证允许这个应用程序。这种解决方案的缺点是：它非常脆弱。