在 Golang 上使用整洁架构（Clean Architecture）- 2

原文：https://medium.com/hackernoon/trying-clean-architecture-on-golang-2-44d615bf8fdf

前言

在写完在 Golang 上使用整洁架构（Clean Architecture）后，我从其他人和 gophers 学习到很多东西。

在我的项目中，我收到了许多邮件、评论甚至是 github issue，这让我更清晰地明白了自己的想法和犯错的地方。

循环导入

在 Golang 上使用整洁架构（Clean Architecture），这个项目和结构仅限于 Golang。我面临的最大问题之一是在 Models 中具有多个抵赖项时。
正如 danf0rth 在此处所说的那样，这导致了循环导入。

包系统

另一件事情是，Golang 和其他语言不同。Golang 正在使用包系统（package system）。换句话说，最好将所有项目的 struct 和 function 存储在一个包中，这样会更安全。我在 golang 的许多库和开源项目中也看到了这一点。我们以 logrus 为例。所有的 struct 和 function 都存储在一个包中，它位于项目包本身的根目录中。因此，我们可以轻松地将 logrus 打包导入我们的所有项目中。

解决了吗

因此，在意识到这一点之后，我尝试了许多方法，同时又不遗漏 Clean Architecture 的概念（独立的、可测试的、可维护的、整洁的），并且没有违背 Golang “身份”（包系统）。最后，我对旧项目进行了更新，详见 https://github.com/bxcodec/go-clean-arch。

避免循环导入

为了避免循环导入，我将 Models 分成一个包。因此，如果我们在模型之间具有关系，则可以解决它，因为它们已经存储在一个包中。

使用包系统还原 Golang “身份”

在不丢失 Golang “身份”的情况下，作为一种程序包编程语言，我将接口（Usecase 和 Repository 层）移至其根域包。

image

article
├── delivery
│   └── http
│       ├── article_handler.go
│       └── article_test.go
├── mocks
│   ├── ArticleRepository.go
│   └── ArticleUsecase.go
├── repository //Encapsulated Implementation of Repository Interface
│   ├── mysql_article.go
│   └── mysqlarticle_test.go
├── repository.go // Repository Interface
├── usecase //Encapsulated Implementation of Usecase Interface
│   ├── articleucase_test.go
│   └── artilce_ucase.go
└── usecase.go // Usecase Interface.

因此，从该项目结构来看，其他域（例如 Author 的域）仅知道接口和功能，而不是实现。

其实，我只是移动 repository 和 usecase 的 interface 到它们的域根。

article/usecase/usecase.go >>>> article/usecase.go
article/repository/repository.go >>>> article/repository.go

并将其实现留在旧文件夹中。通过这些设计，我仍然可以在不更改“合同”的情况下更改其实现。我仍然可以将 repository 实现从 MySQL 更改为 MongoDB，或者我仍然可以更改 usecase 逻辑，而无需更改函数的输出和输入。

测试

这个概念仍然没有改变。还有测试。还是一样。所做的更改仅是为了避免循环导入，还应将 golang “身份”作为程序包编程进行恢复。

最后一项要点

所有这些设计都是基于我自己的经验并向他人学习。也许我从其他源代码中获得了一些特性，但其中一些我做了一些改进。如果我在文章中出现错误或遗漏任何内容，我将非常感谢你提出任何问题，评论或任何修订。

在 Golang 的世界里，没有标准的体系结构，我们可以自由地尝试许多方法。对于某些人来说，我提出的体系结构是有帮助的，但是对于另一些人来说，它确实不适合并且没有解决真正的问题。但是，我想说的是，Golang 是免费的，而且从来没有标准，你可以开发自己的标准，也可以尝试其他人的标准，有很多其他人提出 Clean Architecture，也许可以为你带来更多帮助。

但是，如果你发现这很好并且适合你的问题，请分享并帮助他人解决这个问题。

进一步了解

本文的第三部分