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

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