哪种类型的实施更适合用于服务层？

Question

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

---

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

1. 业务为文件

此方法将公司名称作为文件名。在文件内部，只有一个get公用方法，并且它接收单个参数。该方法调用user-api/contact/{id}。

文件名：contact.service.js

方法：get(id) -> contact

1. API作为文件

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

文件名：user.service.js

方法：getContact(id) -> contact

---

使用这些方法的利弊是什么？

Answer 1

这个问题实际上只是一个意见问题，不同的公司/不同的软件开发人员可能会为您提供不同的答案。

我的看法是，我认为将它们分成单独的文件-如果逻辑很复杂，甚至可以分解为各种方法-对可维护性/测试有很大帮助。

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

向自己问这些问题；

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

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

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