为此用例构建 go 项目

Question

我正在构建一个与多个第三方提供商进行通信的Go服务。此 go-service 充当这些多个提供程序之间的接口，我的内部应用程序仅使用此 Go 服务中的一个 API。我的应用程序现在具有以下结构- app - config - controllers - dto  - exceptions - providers - All external API calls to thrid-party happens here - services - Business logic - tests我必须集成到10多个第三方API中，并且我对如何保留JSON封送和取消编组的结构感到困惑。从维护的角度来看，我对重构应用程序时很少考虑一些事情。每个第三方服务都可以由开发人员独立集成，而不会相互混淆其他人的代码。开发人员可能只知道他/她的第三方集成的集成。每个第三方可能有一些可以利用的常见实用程序，例如：身份验证机制或日志记录或诸如哨兵之类的东西。我应该把所有外部 API 调用的请求和响应的结构放在哪里？我的计划是断续器第三方1请求结构第三方1响应结构第三方2请求结构第三方2响应结构...等等。但是，当我有大约20个第三方API时，会有很多请求 - 响应结构，从可读性的角度来看，目录会太大。我的问题是How would you as a go developer go about structuring the application keeping the above requirements in mind?请忍受这个问题，因为我是编程新手。理解这是固执己见的，但是对于这个特定的用例，它是如何工作的呢？我在网上找不到任何资源。

Answer 1

除了@Muhamed Keta 所写的内容之外，我还要添加一个建议，即为每个提供程序使用子包，而不是一个包含 10 个提供程序的 mega 包。这看起来像这样：

/cmd/app

/config

...

/lib # or /utils 

/providers

    /provider1

        dtos.go

        client.go

        ...

    /provider2

        dtos.go

        client.go

        ...

在 go 中，包名称将成为一个命名空间和客户端代码要使用的非可选标识符/鉴别器。通过这种方式，您可以避免编写更长，冗余且有时断断续续的名称来区分提供商之间的提供商：

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

这也意味着与每个提供程序的实现密切相关的所有代码都位于附近，从而防止名称冲突并帮助仅关注提供程序的开发人员。

我添加了一个（或替代）包，该包将包含可以在许多提供程序之间共享的通用代码。libutils

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

Answer 2

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

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

对于应用程序的其余部分，我喜欢采用扁平结构，仅当存在大量耦合时才进入子目录。在处理程序、数据库（如果有）和外部 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。