什么样的实现会更适合服务层？

Question

我正在开发一个新的微服务应用程序，它将成为包含许多其他微服务的大型架构的一部分。此应用程序需要从其他应用程序获取内容，我想将 HTTP 调用封装到服务层。但我注意到有两种不同的方法。

---

假设我的应用程序将从另一个部署为 User API 的微服务获取联系信息。

1. 业务作为文件

这种方法将企业名称作为文件名。在文件中，只有一个公共方法get，它接收一个参数。该方法调用user-api/contact/{id}。

文件名：contact.service.js

方法：get(id) -> contact

1. API 作为文件

这种方法将 User API 和消费者应用程序之间的所有通信封装到一个文件中。为 User API 提供的每个端点都有一个方法。

文件名：user.service.js

方法：getContact(id) -> contact

---

使用这些方法的优缺点是什么？

Answer 1

这个问题其实更像是一个意见问题，不同的公司/不同的软件开发商可能会给你不同的答案。

我对此的看法是，我认为将它们拆分为单独的文件——如果逻辑复杂，甚至包括方法——对可维护性/测试有很大帮助。

• 测试：如果您在测试文件中使用相同的拆分模式 - 我在结构方面模仿我们的代码并这样做，我发现它可以帮助人们更轻松地定位代码，完全按照他们想要的方式执行测试他们。 Something like test contact.service.test.js 更改被隔离，他们可以非常轻松地立即运行相关测试。
• 可维护性：我尽量在最后一个服务层中保持尽可能小的东西。这并不是说一切都是抽象的，并且一层又一层地你找不到真正的代码/但即使那样我也会将服务拆分为不同文件中的方法，并使用超级方便的名称。通过这种方式编写文档非常简单，您只需在同一个文件中编写所有需要的内容。
• 代码审查：变得容易得多，它强制每个文件中的更改很小，因为您的文件内容少得多。

问自己这些问题；

• 您的服务中是否有非常复杂的逻辑，这会将文件扩展为数千行 - 使记录变得更难/更难发现错误/更难重构？还是它们是逻辑被卸载到系统其他部分的较小端点？

• 这些方法/服务的测试是否将存在于（另一个）单个文件中 - 模仿服务实现中的模式？您能否在测试功能时调用单个测试？

• 您准备好适应您在所有服务中做出的决定了吗？您的特定服务因此该确切文件可能相对较小，那么您的一位同事可能编写并变成巨大的 1K 行文件的服务呢？