清晰架構（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）" , 中詳細描述了程序中使用的依賴注，裏面有兩種類型的工廠,一個是“二級工廠”,另一個是“簡化工廠”。創建“簡化工廠”的原因是爲了簡化代碼，換句話說就是減少代碼行數。

但是當我對設計進行反思時，對程序的複雜性有了不同的理解。我遵循的原則一直都沒有改變，是爲了降低代碼的複雜性。但是我過去認爲代碼越長，就越複雜，但是現在我要增加另一個維度，那就是代碼結構的複雜性。雖然“二級工廠”的代碼要長得多，但結構很簡單。一個工廠建成後，就可以拷貝出許多副本。結構幾乎相同，所以很容易複製工廠，也容易閱讀。它的複雜性時線性增加的，而且沒有其他副作用。此外，你還可以使用諸如代碼生成器之類的工具來自動生成它，以提高效率。雖然“簡化工廠”只有少量代碼，但其結構複雜，當工廠數量增加時其複雜性也迅速增加，而且副作用越來越大太大，難以管理。因此，“二級工廠”看起來代碼很多，但其實很簡單。所以在新的設計中，我決定去掉“簡化工廠”，只保留“二級工廠”。