构建 REST api 同步应用程序时需要考虑哪些架构模式？

Question

TLDR;

我们通过调用第三方 api、映射数据并发布到目标 api 来同步数据。 我们正在整合更多的第三方。 此类软件需要考虑哪些架构模式？

---

细节

我所在的团队构建了一个将数据从一个 REST Api 同步到另一个的解决方案。 我们目前只从一个来源同步到一个目的地。将实施更多来源。

我们开始构建洋葱架构解决方案，它运行良好。 然而：

• 由于我们只想同步（放置或发布）新数据，我们必须先调用目标 api 来查看我们已经拥有的数据。这发生在应用的基础设施层。
• 然后我们调用源 API，并对其进行过滤，以便我们只有新的或更新的数据（也在基础设施层中）
• 数据从第三方对象转换为核心对象（也在基础设施层）
• 然后将其转换为目标对象，并发送到目标 api（也在基础设施层）

_{你可能会看到这是怎么回事..}

大多数数据处理发生在基础设施层，因为核心层独立于一切（项目、nuget 等）。如果我们要完全遵循洋葱模式，我们会在 Core 中进行处理，但这意味着我们必须在比较数据之前进行更多的映射。

我们都觉得核心层中存在的很多东西是不必要的，因为我们基本上只是映射到核心对象，然后直接映射到基础设施对象。

您对我们应该考虑的其他架构有什么建议吗？

Answer 1

软件架构是科学、工程、艺术和工艺的结合。目标是为系统定义一个整体概念模型，使开发人员和维护人员能够灵活地响应需求或环境的变化。

正如 Robert C. Martin 所说（我认为），好的软件架构是关于对未来难以改变的事情做出正确的决定。代码库中的很多东西都很容易改变，我们不应该为这些东西着迷。难以改变的是关于语言、平台、框架、应用技术（例如使用哪个数据库、HTTP 与 Protocol Buffers 等）、同步与异步、ACID 与最终一致等的决策。

换句话说，您首先分析问题，然后选择匹配的架构。

为什么要为上述问题选择 Onion 架构？

关于该架构 (also known as Ports and Adapters, or Hexagonal architecture) 的重点是保护领域模型免受实现细节的影响（换句话说，Dependency Inversion Principle）。

根据OP中的描述，没有业务逻辑可言。相反，这听起来像是ETL 的工作。选择适合该任务的架构。

它可以像Transaction Script 一样简单，也可以更复杂。

几年前，我的一个客户需要实现类似的东西，在那个特定的上下文中，我们一致认为最有意义的是基于pipes and filters architecture 的最终一致的异步守护进程，并加入了一些 CQRS很好的衡量标准。