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

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

爲何建立了一個新項目

我沒有在原來的項目中進行升級，而是建立了一個名爲「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）"