去年，我建立了一個清晰架構（Clean Architecture）微服務框架，它功能強大，但有些重。我寫了一個系列文章來講述它，請參閱["清晰架構（Clean Architecture）的Go微服務"](https://blog.csdn.net/weixin_38748858/article/details/104353016)。 我還指出了設計中存在的一些缺陷，並講到希望以後能修復它們。現在我終於有時間對它進行了改造，結果比我預期的還要好。 我所做的改動不大，但效果驚人。主要的專案結構和介面沒有變，我在那些文章中寫的大部分內容仍然有效。這次升級修復了舊框架中的所有主要問題。現在它幾乎擁有了我理想框架中的所有內容。它是一個輕量級的，但功能強大，並且還是可插拔的。 主要改進如下: + 自我進化的設計 + 第三方庫 + 單獨的事務管理庫 + 其它改動 ### 自我進化的設計 這是所有改動中最突出的。舊的框架有點重，不適合輕量級的專案。升級後，它適合所有型別的專案。你可以改變專案框架本身，使它與你的專案時，你的專案變得更復雜時，你可以改變框架讓它也變得複雜，但你不需要在修改任何業務程式碼。我寫了一篇單獨的文章來講述他，請參閱["一個可以自我進化的微服務框架"](https://blog.csdn.net/weixin_38748858/article/details/106996260) 。 ### 第三方庫 在我的舊框架中，一個很好的設計是日誌介面。有了它，我可以切換到任何其他日誌庫，而不需要更改程式碼(我只需要更改配置檔案)。唯一的缺點是它依賴於框架，不能獨立使用。升級後，我將它從框架中剝離出來，變成了一個獨立的第三方庫，，這樣它就可以單獨使用。它的核心是為元件建立了通用介面，這樣你就可以接入任何實現庫，只要它們實現了通用介面。到目前為止，我建立了三個可接入的元件，[“glogger”](https://github.com/jfeng45/glogger) 用於日誌，[“gmessaging”](https://github.com/jfeng45/gmessaging) 用於訊息傳遞，[“gtransaction”](https://github.com/jfeng45/gtransaction) 用於事務管理。如果有需要，我會新增新的可接入元件。關於如何編寫第三方庫，請參閱["事件驅動的微服務-建立第三方庫"](https://blog.csdn.net/weixin_38748858/article/details/107491297)。 ### 單獨的事務管理庫 舊的框架有一個事務管理系統。它是一個適合於清晰架構（Clean Architecture）的非侵入式架構。儘管它對業務邏輯沒有侵入，但它對我的框架有侵入。另外，它還有一些問題，例如它打破了我的設計結構，我在文章["清晰架構（Clean Architecture）的Go微服務: 日誌管理"](https://blog.csdn.net/weixin_38748858/article/details/103822111) 中有詳細描述。 在新的框架中，我對事務管理部分做了較大的修改。現在，大部分程式碼被移出到第三方庫中。這樣，在應用程式裡只需要新增兩行程式碼就可以讓一個函式支援事務。它不僅對業務程式碼沒有侵入，而且對框架也沒有侵入。因為它是一個第三方庫，所以可以在不使用框架的情況下呼叫。我寫了一篇單獨的文章來講述它， ["一個非侵入的Go事務管理庫——如何使用"](https://blog.csdn.net/weixin_38748858/article/details/106885990)。 ### 其它改動 另外我還做了一些修改，但它們都是小的改動。 #### 容器介面 這是程式容器（Application Container）和業務邏輯之間的介面。我為應用程式容器建立了三個模型，從最簡單的基礎模型到最複雜的高階模型。你可以在不改變業務邏輯的情況下將模型替換為另一個模型。原來的介面是為最複雜的高階模型建立的，我對它做了一點修改，以便更好地適應其他模型。 #### 將持久化程式碼移到應用程式服務層（Application Service Layer) 大多數人都把持久化程式碼在放在領域層（Domain Layer)。但是，根領據域驅動設計，它應該在服務層（Service Layer)，所以我將它移到了應用程式服務層(Application Service Laayer)。乍一看，這很奇怪，因為大多數人並不這樣做。但是，既然我們有規則，就讓我們遵守它來看看這樣做是否合適。 #### 刪除了應用程式容器中的“簡化工廠” 我在文章["清晰架構（Clean Architecture）的Go微服務: 依賴注入（Dependency Injection）"](https://blog.csdn.net/weixin_38748858/article/details/103999523), 中詳細描述了程式中使用的依賴注， 裡面有兩種型別的工廠,一個是“二級工廠”,另一個是“簡化工廠”。建立“簡化工廠”的原因是為了簡化程式碼，換句話說就是減少程式碼行數。 但是當我對設計進行反思時，對程式的複雜性有了不同的理解。我遵循的原則一直都沒有改變，是為了降低程式碼的複雜性。但是我過去認為程式碼越長，就越複雜，但是現在我要增加另一個維度，那就是程式碼結構的複雜性。雖然“二級工廠”的程式碼要長得多，但結構很簡單。一個工廠建成後，就可以拷貝出許多副本。結構幾乎相同，所以很容易複製工廠，也容易閱讀。它的複雜性時線性增加的，而且沒有其他副作用。此外，你還可以使用諸如程式碼生成器之類的工具來自動生成它，以提高效率。雖然“簡化工廠”只有少量程式碼，但其結構複雜，當工廠數量增加時其複雜性也迅速增加，而且副作用越來越大太大，難以管理。因此，“二級工廠”看起來程式碼很多，但其實很簡單。所以在新的設計中，我決定去掉“簡化工廠”，只保留“二級工廠”。 ### 為什麼建立了一個新專案 我沒有在原來的專案中進行升級，而是建立了一個名為“servicetempl1”的新專案，因為我的舊文章仍然指向原來的專案，我不想讓閱讀老版文章的人感到迷惑。我當然認為新版的比舊版好得多，並鼓勵你使用新版的。 ### 原始碼: 完整的原始碼: ["servicetmpl1"](https://github.com/jfeng45/servicetmpl1) ### 索引: [1]["清晰架構（Clean Architecture）的Go微服務"](https://blog.csdn.net/weixin_38748858/article/details/104353016) [2]["一個可以自我進化的微服務框架"](https://blog.csdn.net/weixin_38748858/article/details/106996260) [3]["glogger"](https://github.com/jfeng45/glogger) [4]["gmessaging"](https://github.com/jfeng45/gmessaging) [5]["gtransaction"](https://github.com/jfeng45/gtransaction) [6]["事件驅動的微服務-建立第三方庫"](https://blog.csdn.net/weixin_38748858/article/details/107491297) [7]["清晰架構（Clean Architecture）的Go微服務: 日誌管理"](https://blog.csdn.net/weixin_38748858/article/details/103822111) [8]["一個非侵入的Go事務管理庫——如何使用"](https://blog.csdn.net/weixin_38748858/article/details/106885990) [9] ["清晰架構（Clean Architecture）的Go微服務: 依賴注入（Dependency Injection）"](https://blog.csdn.net/weixin_38748858/article/details/103