本地开发环境的服务更改

Question

我正在开发一个web应用程序和一个后端API。然而，后端必须与其他服务进行对话，其中一些服务是内部服务，而另一些服务则不是。

在理想的情况下，我们将花费时间并让所有服务的本地副本运行，但这是不可能的；有些服务是第三方的，其他内部服务并不是所有团队成员都可以访问的。

因此，当我们无法在本地运行副本时，我想知道如何最好地处理这个问题，并且由于数据同步问题，与实际承载的服务交互并不是一个好主意。

我真的很想避免在代码库中加入if(local) executeMockCall();，但是我不清楚还有什么其他的选择。

Answer 1

反转依赖关系:将外部服务转换为应用程序的插件。然后，根据您是在生产环境中运行还是在开发环境中运行，附加不同的实现。

首先，定义应用程序与第三方服务通信的接口。对于接口，我指的是从代码中的一堆函数到REST，重要的是您可以在运行时选择这个接口的实现。例如，您可以提供一个环境变量，其中包含指向提供预期接口的微服务的URL。或者，您可以在程序开始时选择两个类中的一个。

然后，创建两个接口实现：

• 将您的操作转换为第三方服务的真正实现。
• 产生虚拟结果的测试实现。

关键是，与其在整个代码中选择真正的或模拟的实现，不如使用主代码不确定它所讨论的实现。这是更易测试的，也更不容易出错。决定使用一个特定的实现是一次，最好是在应用程序之外。相反，应该由运行应用程序的环境做出选择。

相关概念：

• 12要素应用程序中的配置和支持服务，是开发SaaS风格软件的指南.
• 避免从业务逻辑到外部组件的依赖的想法也是洋葱建筑思想的一部分：“内部层定义接口。外层实现接口“。这种类型的体系结构有很大的重叠，或者与六角结构(端口和适配器)和干净的体系结构相当。
• 在较低的级别上，用多个类替换重复的if/else称为用多态替换条件重构。

Answer 2

根据外部服务在应用程序中的用途，您可以通过某些配置启用/禁用它们。

对于可选服务，如果由于某种原因其中一个服务不可用，这甚至可能在生产环境中很有用。

如果服务确实是必需的，但必须在dev环境中进行模拟(例如，身份验证子系统)，这可能仍然有效(配置选项不会表示“启用/禁用此服务”，而是“使用模拟而不是真实的服务”)。

如果错误配置可能导致外部服务中的数据损坏，则需要对配置进行适当保护，例如，配置可能从只读配置存储区读取，而不是用户可以编辑的本地配置文件，因此您仍然需要区分dev和prod情况，但这可以在配置模块内完成，不需要在代码中到处传播。