内容简介:去年,我创建了一个清晰架构(Clean Architecture)微服务框架,它功能强大,但有些重。我写了一个系列文章来讲述它,请参阅我所做的改动不大,但效果惊人。主要的项目结构和接口没有变,我在那些文章中写的大部分内容仍然有效。这次升级修复了旧框架中的所有主要问题。现在它几乎拥有了我理想框架中的所有内容。它是一个轻量级的,但功能强大,并且还是可插拔的。主要改进如下:
去年,我创建了一个清晰架构(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"
[7] "清晰架构(Clean Architecture)的Go微服务: 日志管理"
[9] "清晰架构(Clean Architecture)的Go微服务: 依赖注入(Dependency Injection)"
有疑问加站长微信联系
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- SpringCloud微服务架构升级总结
- vivo 商城前端架构升级:总览篇
- 架构升级备战5G 2018年网络回顾
- 滴滴万亿级ElasticSearch平台架构升级解密
- SpringBlade 2.3.1 发布, 升级业务架构
- vivo 商城前端架构升级:前后端分离篇
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Web 2.0 Architectures
Duane Nickull、Dion Hinchcliffe、James Governor / O'Reilly / 2009 / USD 34.99
The "Web 2.0" phenomena has become more pervasive than ever before. It is impacting the very fabric of our society and presents opportunities for those with knowledge. The individuals who understand t......一起来看看 《Web 2.0 Architectures》 这本书的介绍吧!
SHA 加密
SHA 加密工具
RGB CMYK 转换工具
RGB CMYK 互转工具