Golang简洁架构实战

导语：由于golang不像java一样有一个统一的编码模式，并且在同一个组中，不同项目分包可能也不尽相同，所以这篇文章主要借鉴一下clean architecture思想来归纳一下我理想中项目应该怎么规范分包与分层。

文中项目代码位置：https://github.com/devYun/go-clean-architecture

由于golang不像java一样有一个统一的编码模式，所以我们和其他团队一样，采用了Go 面向包的设计和架构分层这篇文章介绍的一些理论，然后再结合以往的项目经验来进行分包：

├── cmd/
│   └── main.go //启动函数
├── etc
│   └── dev_conf.yaml              // 配置文件 
├── global
│   └── global.go //全局变量引用，如数据库、kafka等
├── internal/
│       └── service/
│           └── xxx_service.go //业务逻辑处理类
│           └── xxx_service_test.go 
│       └── model/
│           └── xxx_info.go//结构体
│       └── api/
│           └── xxx_api.go//路由对应的接口实现
│       └── router/
│           └── router.go//路由
│       └── pkg/
│           └── datetool//时间工具类
│           └── jsontool//json 工具类

其实上面的这个划分只是简单的将功能分了一下包，在项目实践的过程中还是有很多问题。比如：

对于功能实现我是通过 function 的参数传递还是通过结构体的变量传递？

使用一个数据库的全局变量引用传递是否安全？是否存在过度耦合？

在代码实现过程中几乎全部都是依赖于实现，而不是依赖于接口，那么将MySQL切换为 MongDB 是不是要修改所有的实现？

所以现在在我们工作中随着代码越来越多，代码中各种 init，function，struct，全局变量感觉也越来越乱。

每个模块不独立，看似按逻辑分了模块，但没有明确的上下层关系，数据流的流向和逻辑也不明确，很难看清代码调用情况。

不过就像《重构》中所说：先让代码工作起来-如果代码不能工作，就不能产生价值；然后再试图将它变好-通过对代码进行重构，让我们自己和其他人更好地理解代码，并能按照需求不断地修改代码。

所以我觉得是时候自我改变一下。

The Clean Architecture

在简洁架构里面对我们的项目提出了几点要求：

1. 独立于框架。该架构不依赖于某些功能丰富的软件库的存在。这允许你把这些框架作为工具来使用，而不是把你的系统塞进它们有限的约束中。
2. 可测试。业务规则可以在没有UI、数据库、Web服务器或任何其他外部元素的情况下被测试。
3. 独立于用户界面。UI可以很容易地改变，而不用改变系统的其他部分。例如，一个Web UI可以被替换成一个控制台UI，而不改变业务规则。
4. 独立于数据库。你可以把Oracle或SQL Server换成Mongo、BigTable、CouchDB或其他东西。你的业务规则不受数据库的约束。
5. 独立于任何外部机构。事实上，你的业务规则根本不知道外部世界的任何情况。

 

上图中同心圆代表各种不同领域的软件。一般来说，越深入代表你的软件层次越高。外圆是战术实现机制，内圆的是战略核心策略。

对于我们的项目来说，代码依赖应该由外向内，单向单层依赖，这种依赖包含代码名称，或类的函数，变量或任何其他命名软件实体。

对于简洁架构来说分为了四层：

• Entities：实体
• Usecase：表达应用业务规则，对应的是应用层，它封装和实现系统的所有用例；
• Interface Adapters：这一层的软件基本都是一些适配器，主要用于将用例和实体中的数据转换为外部系统如数据库或Web使用的数据；
• Framework & Driver：最外面一圈通常是由一些框架和工具组成，如数据库Database, Web框架等；

那么对于我的项目来说，我的项目也分为了四层：

• models
• repo