在阅读了 叔叔的 之后,我尝试在 中实现它。我们公司也有使用相似的架构,, 但是结构有点不同。并不是太不同, 相同的概念,但是文件目录结构不同。
你可以在这里找到一个示例项目,这是一个 管理示例文章
免责声明:
我不推荐使用这里的任何库或框架,你可以使用你自己的或者第三方具有相同功能的任何框架来替换。
基础
在设计简洁架构之前我们需要了解如下约束:
独立于框架。该架构不会依赖于某些功能强大的软件库存在。这可以让你使用这样的框架作为工具,而不是让你的系统陷入到框架的限制的约束中。
可测试性。业务规则可以在没有 , 数据库, 服务或其他外部元素的情况下进行测试。
独立于 。在无需改变系统的其他部分情况下, 可以轻松的改变。例如,在没有改变业务规则的情况下, 可以替换为控制台 。
4 .独立于数据库。你可以用 , , 或者其他数据库来替换 或 ,你的业务规则不要绑定到数据库。
独立于外部媒介。 实际上,你的业务规则可以简单到根本不去了解外部世界。
更多详见:
所以, 基于这些约束,每一层都必须是独立的和可测试的。
如 叔叔的架构有 4 层:
实体层( Entities )
用例层( Usecase )
控制层( Controller )
框架和驱动层( Framework & Driver )
在我的项目里,我也使用了 4 层架构:
模型层( Models )
仓库层( Repository )
用例层 ( Usecase )
表现层( Delivery )
模型层( Models )
与实体( )一样, 模型会在每一层中使用,在这一层中将存储对象的结构和它的方法。例如: 。
所以实体或者模型将会被存放在这一层
仓库层( Repository )
仓库将存放所有的数据库处理器,查询,创建或插入数据库的处理器将存放在这一层,该层仅对数据库执行 操作。 该层没有业务流程。只有操作数据库的普通函数。
这层也负责选择应用中将要使用什么样的数据库。 可以是 , , ,,无论使用哪种数据库,都要在这层决定。
如果使用 , 这层将控制输入,并与 服务对接。
如果调用微服务, 也将在这层进行处理。创建 请求去请求其他服务并清理数据,这层必须完全充当仓库。 处理所有的数据输入,输出,并且没有特定的逻辑交互。
该仓库层( )将依赖于连接数据库 或其他微服务(如果存在的话)
用例层( Usecase )
这层将会扮演业务流程处理器的角色。任何流程都将在这里处理。该层将决定哪个仓库层被使用。并且负责提供数据给服务以便交付。处理数据进行计算或者在这里完成任何事。
用例层将接收来自传递层的所有经过处理的输入,然后将处理的输入存储到数据库中, 或者从数据库中获取数据等。
用例层将依赖于仓库层。
表现层( Delivery )
这一层将作为表现者。决定数据如何呈现。任何传递类型都可以作为是 , 或者是 文件,或者是
这一层将接收来自用户的输入, 并清理数据然后传递给用例层。
对于我的示例项目, 我使用 作为表现方式。客户端将通过网络调用资源节点, 表现层将获取到输入或请求,然后将它传递给用例层。
该层依赖于用例层。
层与层之间的通信
除了模型层, 每一层都需要通过接口进行通信。例如,用例( )层需要仓库( )层,那么它们该如何通信呢?仓库( )层将提供一个接口作为他们沟通桥梁。
仓库层( Repository )接口示例:
用例层( )将通过这个接口与仓库层进行通信,仓库层( )必须实现这个接口,以便用例层( )使用该接口。
用例层接口示例:
与用例层相同, 表现层将会使用这个约定接口。 并且用例层必须实现该接口。
测试
我们知道, 简洁就意味着独立。 甚至在其他层还不存在的情况下,每一层都具有可测试性。
模型( Models )层
该层仅测试任意结构声明的函数或方法。 这可以独立于其他层,轻松的进行测试。
仓库( Repository )层
为了测试该层,更好的方式是进行集成测试,但你也可以为每一个测试进行模拟测试, 我使用 作为我的工具来模拟查询过程
用例( Usecase )层
因为该层依赖于仓库层, 意味着该层需要仓库层来支持测试。所以我们根据之前定义的契约接口制作一个模拟的仓库( Repository )模型。
表现( Delivery )层
与用例层相同,因为该层依赖于用例层,意味着改成需要用例层来支持测试。基于之前定义的契约接口, 也需要对用例层进行模拟。
对于模拟,我使用 的 的模拟库:
仓库层(Repository)测试
为了测试这层,就如我之前所说, 我使用 来模拟我的查询过程。 你可以像我一样使用 ,或者使用其他具有相似功能的库。
用例层(Usecase)测试
用于用例层的示例测试,依赖于仓库层。
Mockery 将会为我生成一个仓库层模型,我不需要先完成仓库()层, 我可以先完成用例(),即使我的仓库(Repository)层尚未实现。
表现层( Delivery )测试
表现层测试依赖于你如何传递的数据。如果使用 , 我们可以使用 中的内置包 。
因为该层依赖于用例( )层, 所以 我们需要模拟 , 与仓库层相同,我使用 模拟我的 来进行表现层( )的测试。
最终输出与合并
完成所有层的编码并通过测试之后。你应该在的根项目的 文件中将其合并成一个系统。
在这里你将会定义并创建每一个环境需求, 并将所有层合并在一起。
以我的 为示例:
你可以看见,每一层都与它的依赖关系合并在一起了。
结论
总之,如果画在一张图上,就如下图所示:
在这里使用的每一个库都可以由你自己修改。因为简洁架构的重点在于:你使用的库不重要, 关键是你的架构是简洁的,可测试的并且是独立的。
我项目就是这样组织的。通过评论和分享, 你可以讨论或者赞成,当然能改善它就更好了。
示例项目
示例项目可以在这里看见:
我的项目中使用到的库:
Glide :包管理工具
go-sqlmock from github.com/DATA-DOG/go-sqlmock
Testify : 测试库
Echo Labstack (Golang Web 框架)用于 表现层
Viper :环境配置
进一步阅读简洁架构 :
。 这是种另一个版本的简洁架构。
如果你任何问题,或者需要更多的解释,或者我在这里没有解释清楚的。你可以通过我的或者联系我。谢谢。
via: https://hackernoon.com/golang-clean-archithecture-efd6d7c43047
作者:Iman Tumorang
译者:fredvence
校对:polaris1119
本文由 GCTT 原创编译,Go语言中文网 荣誉推出
领取专属 10元无门槛券
私享最新 技术干货