清晰架构(Clean Architecture)的Go微服务—重大升级

倚天码农 · · 1458 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

去年,我创建了一个清晰架构(Clean Architecture)微服务框架,它功能强大,但有些重。我写了一个系列文章来讲述它,请参阅"清晰架构(Clean Architecture)的Go微服务"。 我还指出了设计中存在的一些缺陷,并讲到希望以后能修复它们。现在我终于有时间对它进行了改造,结果比我预期的还要好。

我所做的改动不大,但效果惊人。主要的项目结构和接口没有变,我在那些文章中写的大部分内容仍然有效。这次升级修复了旧框架中的所有主要问题。现在它几乎拥有了我理想框架中的所有内容。它是一个轻量级的,但功能强大,并且还是可插拔的。

主要改进如下:

  • 自我进化的设计
  • 第三方库
  • 单独的事务管理库
  • 其它改动

自我进化的设计

这是所有改动中最突出的。旧的框架有点重,不适合轻量级的项目。升级后,它适合所有类型的项目。你可以改变项目框架本身,使它与你的项目时,你的项目变得更复杂时,你可以改变框架让它也变得复杂,但你不需要在修改任何业务代码。我写了一篇单独的文章来讲述他,请参阅"一个可以自我进化的微服务框架"

第三方库

在我的旧框架中,一个很好的设计是日志接口。有了它,我可以切换到任何其他日志库,而不需要更改代码(我只需要更改配置文件)。唯一的缺点是它依赖于框架,不能独立使用。升级后,我将它从框架中剥离出来,变成了一个独立的第三方库,,这样它就可以单独使用。它的核心是为组件创建了通用接口,这样你就可以接入任何实现库,只要它们实现了通用接口。到目前为止,我创建了三个可接入的组件,“glogger” 用于日志,“gmessaging” 用于消息传递,“gtransaction” 用于事务管理。如果有需要,我会添加新的可接入组件。关于如何编写第三方库,请参阅"事件驱动的微服务-创建第三方库"

单独的事务管理库

旧的框架有一个事务管理系统。它是一个适合于清晰架构(Clean Architecture)的非侵入式架构。尽管它对业务逻辑没有侵入,但它对我的框架有侵入。另外,它还有一些问题,例如它打破了我的设计结构,我在文章"清晰架构(Clean Architecture)的Go微服务: 日志管理" 中有详细描述。

在新的框架中,我对事务管理部分做了较大的修改。现在,大部分代码被移出到第三方库中。这样,在应用程序里只需要添加两行代码就可以让一个函数支持事务。它不仅对业务代码没有侵入,而且对框架也没有侵入。因为它是一个第三方库,所以可以在不使用框架的情况下调用。我写了一篇单独的文章来讲述它, "一个非侵入的Go事务管理库——如何使用"

其它改动

另外我还做了一些修改,但它们都是小的改动。

容器接口

这是程序容器(Application Container)和业务逻辑之间的接口。我为应用程序容器创建了三个模型,从最简单的基础模型到最复杂的高级模型。你可以在不改变业务逻辑的情况下将模型替换为另一个模型。原来的接口是为最复杂的高级模型创建的,我对它做了一点修改,以便更好地适应其他模型。

将持久化代码移到应用程序服务层(Application Service Layer)

大多数人都把持久化代码在放在领域层(Domain Layer)。但是,根领据域驱动设计,它应该在服务层(Service Layer),所以我将它移到了应用程序服务层(Application Service Laayer)。乍一看,这很奇怪,因为大多数人并不这样做。但是,既然我们有规则,就让我们遵守它来看看这样做是否合适。

删除了应用程序容器中的“简化工厂”

我在文章"清晰架构(Clean Architecture)的Go微服务: 依赖注入(Dependency Injection)", 中详细描述了程序中使用的依赖注, 里面有两种类型的工厂,一个是“二级工厂”,另一个是“简化工厂”。创建“简化工厂”的原因是为了简化代码,换句话说就是减少代码行数。

但是当我对设计进行反思时,对程序的复杂性有了不同的理解。我遵循的原则一直都没有改变,是为了降低代码的复杂性。但是我过去认为代码越长,就越复杂,但是现在我要增加另一个维度,那就是代码结构的复杂性。虽然“二级工厂”的代码要长得多,但结构很简单。一个工厂建成后,就可以拷贝出许多副本。结构几乎相同,所以很容易复制工厂,也容易阅读。它的复杂性时线性增加的,而且没有其他副作用。此外,你还可以使用诸如代码生成器之类的工具来自动生成它,以提高效率。虽然“简化工厂”只有少量代码,但其结构复杂,当工厂数量增加时其复杂性也迅速增加,而且副作用越来越大太大,难以管理。因此,“二级工厂”看起来代码很多,但其实很简单。所以在新的设计中,我决定去掉“简化工厂”,只保留“二级工厂”。

为什么创建了一个新项目

我没有在原来的项目中进行升级,而是创建了一个名为“servicetempl1”的新项目,因为我的旧文章仍然指向原来的项目,我不想让阅读老版文章的人感到迷惑。我当然认为新版的比旧版好得多,并鼓励你使用新版的。

源码:

完整的源码: "servicetmpl1"

索引:

[1]"清晰架构(Clean Architecture)的Go微服务"

[2]"一个可以自我进化的微服务框架"

[3]"glogger"

[4]"gmessaging"

[5]"gtransaction"

[6]"事件驱动的微服务-创建第三方库"

[7]"清晰架构(Clean Architecture)的Go微服务: 日志管理"

[8]"一个非侵入的Go事务管理库——如何使用"

[9] "清晰架构(Clean Architecture)的Go微服务: 依赖注入(Dependency Injection)"


有疑问加站长微信联系(非本文作者)

本文来自:Segmentfault

感谢作者:倚天码农

查看原文:清晰架构(Clean Architecture)的Go微服务—重大升级

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1458 次点击  
加入收藏 微博
被以下专栏收入,发现更多相似内容
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传