領域驅動（DDD）之我見，基於Golang實現

分享一點不成熟的理解，還請本著交流進步的大原則噴之。從去年開始接觸和套用DDD以來，已經有1年多時間了。也先後在2個生產項目中主導應用，都是基於.Net Core的，完全參考https://github.com/EduardoPires/EquinoxProject 該項目搭建的基礎架構。

一、一些概念

　　DDD經典分層：

 

 

 分層架構的一個重要原則是：每層只能與位於其下方的層發生耦合。嚴格分層架構，某層只能與直接位於其下方的層發生耦合；鬆散分層架構，則允許任意上方層與任意下方層發生耦合。大原則如此，我一般都是採用鬆散分層，嚴格的太誇張，在團隊裡推廣起來挺難的。

　　CQRS：

　　命令查詢職責分離，是由Betrand Meyer（Eiffel語言之父，OCP提出者）提出來的。命令(Command):不返回任何結果(void)，但會改變對象的狀態。查詢(Query):返回結果，但是不會改變對象的狀態，對系統沒有副作用。在我的實踐過程中，其實還是讓命令返回了一些主鍵之類的。

　　ES事件溯源：

　　在CQRS中，每一個確定的命令操作，不論成功還是失敗，只要執行之後就產生相應的事件（Event）。這樣只需要把所有系統啟動並執行Event，以及其產生時的資料記錄起來，這就是系統的記錄了，並且能夠方便的復原到某一曆史狀態。Event Sourcing就是用來進行儲存和管理事件的。

　　粗略的知道了這幾個概念之後，基本上就可以用來理解和構建最基礎的領域驅動架構了。

二、一般實踐

　　總體分層結構如下：

　　1.presentation 表現層。Web架構選擇了BeeGo，Beego是基於MVC的。我將V和C層都放在了表現層。路由設定、Views、以及Controllers這些統在一起都算是表現層的。領域驅動設計，更多關注的是業務，以及其變更時能夠比較好的擴充與維護。表現層邏輯也很簡單，主要是承接Beego架構轉寄過來的請求，然後通過memoryBus將請求發布出去，至於是誰訂閱了該請求，統一委託給 第三方 HttpServer來處理，這也是 迪米特法則的精要。解除了表現層或者說web請求與具體的處理該請求的商務服務的直接關聯（耦合）。這樣做的好處，只舉一例。業務層可以是獨立的分布式服務，不一定跟表現層在一個進程服務裡。

　

　　2.application應用程式層。DDD裡應用程式層是很薄的一層，只作為電腦領域到業務領域的過渡層。比如電腦能夠識別和傳輸的肯定是2進位位元組流，這一層可以充當翻譯，把這些晦澀難懂的機器“語言”，轉化為領域業務人員建模出來的語言。或者說是進階電腦程式設計語言，這裡一般會有專門的ViewMode來承接所需的參數資料。這一層直接消費領域層，並且開始記錄一些系統型功能，比如日誌、事件溯源。

　　3. domain領域層。領域驅動設計裡最核心的部分了，可以細拆分為彙總根、實體，領網域服務等一大堆其他概念。這裡不展開詳細說明了，簡單的理解下 彙總根，負責整個彙總業務的所有功能就行了。這裡已Protocol協議為例，該類直接負責完與協議相關的所有業務，對內各種封裝，完成所有所需的功能，由彙總根對外統一提供方法。

　　4. infrastructure基礎架構層。這一層一般主要將所有公用功能抽象整理出來，作為獨立的對外輸出一些協助類等。但我這裡只是重點放置了倉儲功能，也就是和資料庫打交道的功能。這一層也是講求和商務邏輯無關，只重點提供通用的功能。

　　5.crossutting、ddd_interfaces、dddcore，這些都不是DDD經典分層裡的，主要是用來方便實現DDD所增加和分離出來的一些介面、和基礎概念實現。

三、一點感悟

　　對DDD的理解和應用其實還很不成熟，只是對過去的一點總結。Golang 也是新手，只是看了一遍《Go語言聖經》以及astaxie大神的使用Golang構建web應用。

　　確實很Go的物件導向設計，沒有繼承，而是採用組合的方式來實現OO裡的“繼承”。儘可能的使用組合而不是繼承，也算是物件導向設計的一個原則，Golang天然就直接遵循了。“封裝”也很有意思，直接通過首字母是否大小寫，“多態”還沒怎麼瞭解透徹就不可描述了。再使用Golang實現DDD的時候，也發現了如果有“泛型”就好了的感概。這個時候更能深刻的理解和體會，泛型的好處。不得不佩服下C#的設計者，很早就有了泛型。

　　簡單的構造出來了一個DDD的實現，不成熟的地方還有很多，但是迭代是個好東西，慢慢的理解和完善。

　　代碼地址： https://github.com/KendoCross/kendoDDD