Go Clean Architecture 实现

之前阅读了《Clean Architecture》，结合一些个人理解，用Golang实现一个实现整洁架构的业务开发框架，我们回顾下整洁架构的主要要素：

框架独立性，不依赖于特定的软件库框架，这样你可以像工具一样使用这种框架，而不需要让你的系统受到它的约束条件；
可测试性，可以在没有 UI、数据库、Web 服务器或任何其他外部依赖的情况下可以测试业务规则；
UI独立性，UI 可以轻松更改，而无需更改系统的其余部分；
数据库独立性，可以将 Oracle 或 SQL Server 换成 Mongo、BigTable、CouchDB 或其他东西；
外部依赖独立性，事实上业务逻辑代码不应该和外部具体实现打交道；

Bob大叔的整洁架构主要包含四层：

Entity
Usecase
Controller
Framework & Driver

我们结合golang项目推荐做法和Bob大叔的整洁架构思想来做项目划分

Golang standard project layout

对于golang项目组织架构可以参考golang-standards/project-layout 虽然这些不是强制性的，但是如果有去看一些开源项目基本也是这样组织的，我们可以作为参考

/cmd目录

本项目的主干，每个应用程序的目录名应该与你想要的可执行文件的名称相匹配(例如，/cmd/myapp)

不要在这个目录中放置太多代码。如果你认为代码可以导入并在其他项目中使用，那么它应该位于 /pkg 目录中。如果代码不是可重用的，或者你不希望其他人重用它，请将该代码放到 /internal 目录中。你会惊讶于别人会怎么做，所以要明确你的意图!

通常有一个小的 main 函数，从 /internal 和 /pkg 目录导入和调用代码，除此之外没有别的东西。

/internal

私有应用程序和库代码。这是你不希望其他人在其应用程序或库中导入代码。请注意，这个布局模式是由 Go 编译器本身执行的。有关更多细节，请参阅Go 1.4 release notes 。注意，你并不局限于顶级 internal 目录。在项目树的任何级别上都可以有多个内部目录。

你可以选择向 internal 包中添加一些额外的结构，以分隔共享和非共享的内部代码。这不是必需的(特别是对于较小的项目)，但是最好有有可视化的线索来显示预期的包的用途。你的实际应用程序代码可以放在 /internal/app 目录下(例如 /internal/app/myapp)，这些应用程序共享的代码可以放在 /internal/pkg 目录下(例如 /internal/pkg/myprivlib)。

/pkg

外部应用程序可以使用的库代码(例如 /pkg/mypubliclib)。其他项目会导入这些库，希望它们能正常工作，所以在这里放东西之前要三思:-)注意，internal 目录是确保私有包不可导入的更好方法，因为它是由 Go 强制执行的。/pkg 目录仍然是一种很好的方式，可以显式地表示该目录中的代码对于其他人来说是安全使用的好方法。由 Travis Jeffery 撰写的 I'll take pkg over internal 博客文章提供了 pkg 和 internal 目录的一个很好的概述，以及什么时候使用它们是有意义的。

如果你的应用程序项目真的很小，并且额外的嵌套并不能增加多少价值(除非你真的想要:-)，那就不要使用它。当它变得足够大时，你的根目录会变得非常繁琐时(尤其是当你有很多非 Go 应用组件时)，请考虑一下。

/api

OpenAPI/Swagger 规范，JSON 模式文件，协议定义文件，参考：

api目录可以按照产品线、业务模块、版本号进行划分

.
└── api
    └── product_name // product name
        └── app_name // application name
            └── v1   // version
                └── v1.proto

/configs

配置文件模板或默认配置，例如json或者yaml格式的配置文件

/scripts

执行各种构建、安装、分析等操作的脚本，参考：

/deploy

IaaS、PaaS、系统和容器编排部署配置和模板

/test

额外的外部测试应用程序和测试数据。你可以随时根据需求构造 /test 目录。对于较大的项目，有一个数据子目录是有意义的。例如，你可以使用 /test/data 或 /test/testdata (如果你需要忽略目录中的内容)。请注意，Go 还会忽略以“.”或“_”开头的目录或文件，因此在如何命名测试数据目录方面有更大的灵活性。

/docs

设计和用户文档(除了 godoc 生成的文档之外)。

其他总结：

一般而言，在 Go 项目当中不应该出现 src 目录，Go 和 Java 不同，在 Go 中每一个目录都是一个包，每一个包都是一等公民，当然也有一些开源项目会出现src目录，不过相对比较少

此外最好不要在项目中出现 utils 和 common 这种包，长久之后这个包里面都有，因为大家会把不知道丢哪个目录的文件都会丢在这个目录下

通常来说一个大team或者整个公司，应该有一个golang kit开发库，这个库有专门的开发维护，提供一些通用的功能，例如logging/metric/tracing，database/cache封装方法，config管理方法，以及一些常用的lib。对于这个kit仓库，需要有良好的抽象，支持插件，减少依赖，避免每个小组各自维护一套自己的kit库

Golang clean architecture

对于每个项目其实都会按照模块不同划分不同的服务模块：

admin服务，通常来说是面向运营人员的系统，具有很高的数据权限；
interface服务，或者是portal服务，通常来说是面向BFF层的服务，接受来自用户的请求，比如暴露了 HTTP/gRPC 接口；
inner service服务，对内的微服务，仅接受来自内部其他服务或者网关的请求，比如暴露了 gRPC 接口只对内服务；
job服务，流式任务处理的服务，上游一般依赖 message broker；
task定时任务，类似 cronjob，定时执行一些任务；

对于这种项目，我们可以新增app目录，然后把每个子项目丢在这个目录下，每个子项目的结构按照上面的项目布局，最终整个项目的结构大概是：

.
├── Makefile
├── README.md
├── api
│   ├── admin
│   ├── portal
│   └── service
├── app
│   ├── admin
│   ├── inner
│   ├── job
│   ├── portal
│   └── task
├── deploy
├── docs
├── go.mod
├── pkg
├── scripts
└── third_party

每个子项目的架构大概是：

.
├── Makefile
├── README.md
├── cmd
│   └── main.go
├── configs
│   └── config.yaml
└── internal
    ├── biz
    │   ├── billing
    │   ├── campaign
    │   ├── contract
    │   └── order
    ├── conf
    │   └── conf.go
    ├── repo
    │   ├── billing
    │   ├── campaign
    │   ├── contract
    │   └── order
    ├── server
    │   ├── grpc.go
    │   └── http.go
    └── service
        ├── billing
        ├── campaign
        ├── contract
        └── order

biz 业务逻辑的组装层，类似 DDD 的 domain 层，包含entity实体定义、usecase业务逻辑，repo 接口在这里定义，使用依赖倒置的原则；
repo 包含PO持久对象定义。包含PO持久对象定义，包含 cache、db 等封装，同时实现了 biz 的 repo 接口；
service 实现了 api 定义的服务层，类似 DDD 的 application 层，处理 DTO 到 biz 领域实体的转换(DTO -> DO)，同时协同各类 biz 交互，但是不应处理复杂逻辑；
server rpc服务和http服务启动管理，这个目录内容很少主要是生命周期管理；

参考资料：

1.https://medium.easyread.co/golang-clean-archithecture-efd6d7c43047

2.https://medium.easyread.co/trying-clean-architecture-on-golang-2-44d615bf8fdf

3.https://github.com/bxcodec/go-clean-arch

4.https://github.com/golang-standards/project-layout/blob/master/README_zh.md

5.https://go-kratos.dev/