Golang 子项目或子模块依赖
Golang subproject or submodule dependency
Golang 推荐的下载依赖子模块的方式是什么？我认为我的问题可以用例子来最好地描述。
示例 #1：
我有一个客户端和一个服务器。我的服务器是一个 API 并且有很多其他依赖项，例如数据库、消息队列、consul 等。我希望我的 客户端是一个轻量级包 其中用户只下载客户端所需的少量依赖项。
您可以说客户端和服务器可以位于不同的存储库中。但是，它们之间可能还有一些通用代码，如果我们遵循这种模式，它们将再次成为另一个存储库。
我在想一些看起来像这样的结构：
service/
---> common/
------> redis.go
------> kafka.go
---> client/
------> client.go
---> server/
------> database/
------> swagger/
------> producer/
------> etc/
示例 #2：
项目共享模型是很常见的。如果我们有通过具有通用模型的消息代理进行通信的微服务，我们可能需要这样的结构。
service/
---> model/
------> message.go
---> service1/
---> service2/
与其他语言的比较
我是Scala/Java出身，开始使用Golang不到一个月。与 Scala 相比，我可以用两种方式处理这个问题。让我们以示例#2
为例
- 将模型发布为自己的 jar 并在每个服务中导入
model.jar
- 在 sbt 中使用多项目设置：https://www.scala-sbt.org/1.x/docs/Multi-Project.html。
我在 Go 中探索的一些事情
- https://blog.gopheracademy.com/advent-2015/vendor-folder/
- https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories
但到目前为止他们似乎没有解决我的问题
最后一个问题
Golang 中推荐的解决示例中所述问题的方法是什么？
感谢您的帮助！
一般来说，尽量坚持一个代码库和一个模块。将您的代码库拆分为多个存储库 and/or 多个模块会产生随时间增长的成本。您需要在自己的模块之间定义明确的版本依赖关系，谨慎地进行分阶段升级等。特别是对于 small-to-medium 项目，一个 repo 和一个模块是最好的方法。
关于您在示例 1 中的具体要求，如果“客户端”的用户不拉取“服务器”代码至关重要，那么客户端和服务器必须在单独的模块。这些模块可以在同一个仓库中，也可以在不同的仓库中——这对 Go 没有影响。通用代码必须在其自己的模块中，例如：
github.com/user/myrepo/
client/
go.mod
server/
go.mod
common/
go.mod
然后，使用您的客户端的模块将在 go.mod:
require github.com/user/myrepo/client <version>
这将拉入 client 和 common，但不会拉入 server。
如果服务器可以依赖于客户端，您可以将 common 作为 client 的一部分，但我不确定这会节省多少。
对于示例 2，思路类似 - 通用代码可以放入其自己的模块中。
我强烈建议您阅读 Using Go Modules 上的官方博文。
有关带有模块的简单 Go 项目布局，请参阅 this post
Golang 推荐的下载依赖子模块的方式是什么？我认为我的问题可以用例子来最好地描述。
示例 #1：
我有一个客户端和一个服务器。我的服务器是一个 API 并且有很多其他依赖项，例如数据库、消息队列、consul 等。我希望我的 客户端是一个轻量级包 其中用户只下载客户端所需的少量依赖项。
您可以说客户端和服务器可以位于不同的存储库中。但是，它们之间可能还有一些通用代码，如果我们遵循这种模式，它们将再次成为另一个存储库。
我在想一些看起来像这样的结构：
service/
---> common/
------> redis.go
------> kafka.go
---> client/
------> client.go
---> server/
------> database/
------> swagger/
------> producer/
------> etc/
示例 #2：
项目共享模型是很常见的。如果我们有通过具有通用模型的消息代理进行通信的微服务，我们可能需要这样的结构。
service/
---> model/
------> message.go
---> service1/
---> service2/
与其他语言的比较
我是Scala/Java出身，开始使用Golang不到一个月。与 Scala 相比，我可以用两种方式处理这个问题。让我们以示例#2
为例- 将模型发布为自己的 jar 并在每个服务中导入
model.jar - 在 sbt 中使用多项目设置：https://www.scala-sbt.org/1.x/docs/Multi-Project.html。
我在 Go 中探索的一些事情
- https://blog.gopheracademy.com/advent-2015/vendor-folder/
- https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories
但到目前为止他们似乎没有解决我的问题
最后一个问题
Golang 中推荐的解决示例中所述问题的方法是什么？
感谢您的帮助！
一般来说，尽量坚持一个代码库和一个模块。将您的代码库拆分为多个存储库 and/or 多个模块会产生随时间增长的成本。您需要在自己的模块之间定义明确的版本依赖关系，谨慎地进行分阶段升级等。特别是对于 small-to-medium 项目，一个 repo 和一个模块是最好的方法。
关于您在示例 1 中的具体要求，如果“客户端”的用户不拉取“服务器”代码至关重要，那么客户端和服务器必须在单独的模块。这些模块可以在同一个仓库中，也可以在不同的仓库中——这对 Go 没有影响。通用代码必须在其自己的模块中，例如：
github.com/user/myrepo/
client/
go.mod
server/
go.mod
common/
go.mod
然后，使用您的客户端的模块将在 go.mod:
require github.com/user/myrepo/client <version>
这将拉入 client 和 common，但不会拉入 server。
如果服务器可以依赖于客户端，您可以将 common 作为 client 的一部分，但我不确定这会节省多少。
对于示例 2，思路类似 - 通用代码可以放入其自己的模块中。
我强烈建议您阅读 Using Go Modules 上的官方博文。
有关带有模块的简单 Go 项目布局，请参阅 this post