清晰架构（Clean Architecture）的Go微服务: 程序结构

我使用Go和gRPC创建了一个微服务，并试图找出最佳的程序结构，它可以用作我未来程序的模板。 我有Java背景，并发现自己在Java和Go之间挣扎，它们之间的编程理念完全不同。我写了一系列关于在项目工作中做出的设计决策和取舍的文章。 这是其中的第一篇， 是关于程序结构的。

程序结构的资源

Go的标准程序结构的最佳资源可能是Github上的标准Go程序结构¹，但它不适合我的项目。在阅读了Sylvain Wallez的文章²之后，我终于得到了一些关于其背后原因的信息。 Go起初是专为API和网络服务器而设计，Github上的大多数Go项目都是以库的形式编写的，因此“标准Go程序结构”可能非常适合。 商业微服务项目是一种完全不同的动物，需要不同的程序结构。但我还是采用了“标准Go程序结构”中适用的一些建议，这些建议约占30％。

一般来说，创建应用程序结构有两种不同的方法：基于业务功能或基于技术结构。大家的共识³是基于业务功能的更好，对于单体项目（monolithic project）来说也确实如此。在微服务架构中，情况发生了变化，因为每个服务都有自己的源码库，这相当于已经把应用程序按业务功能查分成了一个个的微服务。因此，在每个微服务中，基于技术结构创建项目结构实际上是可行的。

我还找到了Ben Johnson关于应用程序结构⁴和包结构⁵的一些好建议。但它没有为我的项目提供完整的解决方案，所以我决定创建自己的程序结构。程序结构取决于项目要求，以下是需求。

项目需求:

1.在数据持久层上支持不同的数据库（Sql和NoSql数据库）

2.使用不同的协议（如gRPC或REST）支持来自其他微服务的数据

3.松散耦合和高度内聚

4.支持简单一致的日志记录，并能够更改它（例如，日志记录级别和日志记录库），而无需修改程序中的日志记录语句。

5.支持业务级别的事物交易。

程序结构也受到程序设计的影响。 我采用了 Bob Martin的清晰架构（Clean Architecture）⁶ 和