干净的架构The Clean Architecture 这是著名软件大师Bob大叔提出的一种架构,也是当前各种语言开发架构.干净架构提出了一种单向依赖关系,从而从逻辑上形成一种向上的抽象系统. 我们经常听说过如下各种架构: 六边形架构Hexagonal Architecture (也称为 端口和适配器) 这是由Alistair Cockburn 提出,被Steve Freeman和 Nat Pryce在他们的书籍Growing Object Oriented Software中采取的. Onio…

我使用Go和gRPC创建了一个微服务,并试图找出最佳的程序结构,它可以用作我未来程序的模板. 我有Java背景,并发现自己在Java和Go之间挣扎,它们之间的编程理念完全不同.我写了一系列关于在项目工作中做出的设计决策和取舍的文章. 这是其中的第一篇, 是关于程序结构的. 程序结构的资源 Go的标准程序结构的最佳资源可能是Github上的标准Go程序结构¹,但它不适合我的项目.在阅读了Sylvain Wallez的文章²之后,我终于得到了一些关于其背后原因的信息. Go起初是专为API和网络服务…

我最近写了一个Go微服务应用程序,这个程序的设计来自三个灵感: 清晰架构"Clean Architecture"¹ and SOLID (面向对象设计)² 设计 原则³ Spring的容器技术(Spring's application context)⁴ Go的简洁设计⁵ 特别是 Go的面向对象的设计⁶ 我使用Spring的基于接口的编程和依赖注入(Dependency Injection)来实现Bob Martin的清晰架构(Clean Architecture),并遵循了Go的简单…

清晰架构(Clean Architecture)的一个理念是隔离程序的框架,使框架不会接管你的应用程序,而是由你决定何时何地使用它们.在本程序中,我特意不在开始时使用任何框架,因此我可以更好地控制程序结构.只有在整个程序结构布局完成之后,我才会考虑用某些库替换本程序的某些组件.这样,引入的框架或第三方库的影响就会被正确的依赖关系所隔离.目前,除了logger,数据库,gRPC和Protobuf(这是无法避免的)之外,我只使用了两个第三方库ozzo-validation¹和YAML²,而其他所有库…

在清晰架构(Clean Architecture)中,应用程序的每一层(用例,数据服务和域模型)仅依赖于其他层的接口而不是具体类型. 在运行时,程序容器¹负责创建具体类型并将它们注入到每个函数中,它使用的技术称为依赖注入². 以下是要求. 容器包的依赖关系: 容器包是唯一依赖于具体类型和许多外部库的包,因为它需要创建具体类型. 本程序中的所有其他软件包主要仅依赖于接口. 外部库可以包括DB和DB连接,gRPC连接,HTTP连接,SMTP服务器,MQ等. #2中提到的具体类型的资源链接只需要创建一…

编码风格在编程中是一个相对乏味的主题,但是合适的编码风格对一个有效的程序员是至关重要的. 它有三个组成部分: 程序结构 ( application layout) 编码规则或风格 命名约定 我已经在清晰架构(Clean Architecture)的Go微服务: 程序结构¹中讨论了程序结构,因此本文将介绍后两点. 编码规则或风格 没有包级别(package level)变量. 包级别变量打破了函数封装并使函数有了不确定.我在本程序中遵循了这个规则,唯一的例外是在"容器"包中,因为它负责程…

我用Go和gRPC创建了一个微服务项目,并试图找出最好的程序结构,它可以作为我其他项目的模板.我还将程序设计和编程的最佳实践应用于Go Microservice程序,例如清晰架构(Clean Architecture),依赖注入(Dependency Injection),日志记录,错误处理等.我有Java背景,并发现自己在Java和Go之间挣扎,它们之间的编程理念完全不同.我写了一系列关于在项目工作中做出的设计决策和取舍的文章. 阅读这些文章不需要熟悉Go,但如果你有Go基础绝对会有帮助.如果…

我使用Go和gRPC创建了一个微服务,并将程序设计和编程的最佳实践应用于该项目. 我写了一系列关于在项目工作中做出的设计决策和取舍的文章,此篇是关于程序设计. 程序的设计遵循清晰架构(Clean Architecture)¹. 业务逻辑代码分三层:用例(usecase),域模型(model)和数据服务(dataservice). 有三个顶级包"usecase","model"和"dataservice",每层一个. 在每个顶级包(模型除外)中只有…

去年,我创建了一个清晰架构(Clean Architecture)微服务框架,它功能强大,但有些重.我写了一个系列文章来讲述它,请参阅"清晰架构(Clean Architecture)的Go微服务". 我还指出了设计中存在的一些缺陷,并讲到希望以后能修复它们.现在我终于有时间对它进行了改造,结果比我预期的还要好. 我所做的改动不大,但效果惊人.主要的项目结构和接口没有变,我在那些文章中写的大部分内容仍然有效.这次升级修复了旧框架中的所有主要问题.现在它几乎拥有了我理想框架中的所有内容.…

为了支持业务层中的事务,我试图在Go中查找类似Spring的声明式事务管理,但是没找到,所以我决定自己写一个. 事务很容易在Go中实现,但很难做到正确地实现. 需求: 将业务逻辑与事务代码分开. 在编写业务用例时,开发者应该只需考虑业务逻辑,不需要同时考虑怎样给业务逻辑加事务管理.如果以后需要添加事务支持,你可以在现有业务逻辑的基础上进行简单封装,而无需更改任何其他代码.事务实现细节应该对业务逻辑透明. 事务逻辑应该作用于用例层(业务逻辑) 不在持久层上. 数据服务(数据持久性)层应对事务逻辑透…