转载

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

去年，我创建了一个清晰架构（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）" , 中详细描述了程序中使用的依赖注，里面有两种类型的工厂,一个是“二级工厂”,另一个是“简化工厂”。创建“简化工厂”的原因是为了简化代码，换句话说就是减少代码行数。

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