为这个用例构造go项目

Question

我正在构建一个与多个第三方提供商进行通信的Go服务。这个Go服务充当这些多个提供者之间的接口，而我的内部应用程序只使用这个Go服务中的一个API。

我的应用程序现在具有以下结构

- app
- config
- controllers
- dto 
- exceptions
- providers - All external API calls to thrid-party happens here
- services - Business logic
- tests

我需要集成到10多个第三方API中，我对如何保持JSON封送和解编组的结构感到困惑。

从维护的角度来看，我在重构应用程序时记住了很少的事情。

• 每个第三方服务都可以由开发人员独立集成，而不影响其他人的代码。开发人员可能只需要知道他/她的第三方集成的集成。

• 每个第三方都可能有一些可以使用的通用实用程序，例如:身份验证机制或日志记录或类似sentry.

之类的东西。

• 在哪里放置所有外部API调用的请求和响应的结构？

我当时计划的是

• thirdparty1RequestStruct
• thirdparty1ResponseStruct
• thirdparty2RequestStruct
• thirdparty2ResponseStruct .所以on.

但是，当我有大约20个第三方API时，会有很多请求响应结构，从可读性的角度来看，目录太大了。

我的问题是

How would you as a go developer go about structuring the application keeping the above requirements in mind?

请容忍这个问题，因为我是很新的去编程。明白这是自以为是的，但是对于这个特定的用例，它是如何工作的呢？我在网上找不到任何资源。

Answer 1

除了@Muhamed所写的内容外，我还建议为每个提供商使用子包，而不是一个包含10 s提供者的巨型包。这个应该是这样的：

/cmd/app
/config
...
/lib # or /utils 
/providers
    /provider1
        dtos.go
        client.go
        ...
    /provider2
        dtos.go
        client.go
        ...

在go中，包名成为命名空间和非可选标识符/鉴别器，供客户端代码使用。通过这种方式，您不必编写更长的、冗余的、有时口吃的名称来区分提供者和提供者：

因此，在使用提供程序而不是编写providers.Provider1Client的代码中，您将拥有provider1.Client。这似乎是一种常见的围棋模式/最佳实践。

这也意味着与每个提供程序的实现密切相关的所有代码都生活在很近的地方，防止名称冲突，并帮助只关注提供者的开发人员。

我已经添加了一个lib (或者utils)包，它包含可能在许多提供者之间共享的通用代码。

这是主观的，但希望我已经概述了一些合理的优点，因为语言的限制。

Answer 2

首先，请注意，这个问题在某种程度上是固执己见的，没有正确的答案。

就我个人而言，我喜欢拥有一个cmd/app、config子目录，因为它们包含启动/运行应用程序的逻辑，这样捆绑时我感觉很好。

对于应用程序的其余部分，我喜欢有一个扁平的结构，只有当有很大的耦合时才进入子目录。在处理程序、数据库(如果有)和外部API(如果有的话)之间分离层是很重要的。

我建议如下：

/cmd/app
/config
/provider
  provider1.go // contains the request response structs in itself
  provider2.go // contains the request response structs in itself
provider.go

最后，更多的代码看起来可能不太容易维护，但它比重耦合的代码更好。如果一个API突然决定切换有效负载格式，那么在其中一个文件中找到整个过程要容易得多，而不是在非常不同的子目录中浏览3。