go - 为这个用例构建 go 项目

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

去年关闭。




Improve this question




我正在构建一个与多个第三方提供商通信的 Go 服务。这个 go-service 充当这些多个提供者之间的接口(interface)，我的内部应用程序只使用这个 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 调用的请求和响应结构？

我的计划是

dto

第三方1RequestStruct

第三方1ResponseStruct

第三方2RequestStruct

第三方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 个提供者的巨型包。这看起来像这样:

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

在 go 中，包名成为一个命名空间和一个非可选的标识符/鉴别器，供客户端代码使用。通过这种方式，您可以避免编写更长、多余且有时口吃的名称来区分提供者与提供者:
所以在代码中使用你的提供者而不是写 providers.Provider1Client你会有 provider1.Client .这似乎是一种常见的围棋模式/最佳实践。
这也意味着与每个提供者的实现密切相关的所有代码都在附近，防止名称冲突并帮助专注于提供者的开发人员。
我添加了 lib (或者 utils )包，其中包含可以在许多提供者之间共享的通用代码。
这是主观的，但鉴于语言的限制，希望我已经概述了一些合理的优点。