從程式碼戰術角度解釋領域驅動設計 - Cyrille

對於大多數簡單的用例來說都很好。它的可讀性很強，幾乎不可測試，而且都在一個地方。
它只是完成工作。但是有很多警告：

• 程式碼根本不反映域，只有函式名createUser說明發生了什麼
• 該方法處理不同層次的抽象。從一個物件中提取資料是一個低階操作，做一個SQL查詢就更底層了。這是兩個不同層次的細節。
• 該方法有太多責任：它處理從請求中獲取輸入、進行資料庫查詢和傳送響應。您必須瞭解許多實施細節：此程式碼明確使用 SQL 資料庫，並且可能透過 HTTP API 呼叫進行呼叫。

透過這個小動作，我們抽象出了資料庫實現細節。無論使用者如何儲存，只要知道該save方法會為您完成就足夠了。
但是現在我們有另一個問題：邏輯重複。如果另一個用例需要進行相同的操作（例如，從管理皮膚建立使用者），您別無選擇，只能複製並貼上相同的程式碼。
聽起來不是很重要嗎？那是因為我們的用例非常簡單。如果註冊實際上是一項複雜的操作，需要傳送電子郵件、OTP、簽署檔案、建立實體、填寫 CRM、通知報告和分析等等，該怎麼辦？突然之間，您需要做很多工作來確保一致性。

這就是您進入 DDD 領域的地方。作為非常簡單的第一步，您可以轉換您的 Active Record 並讓它封裝域邏輯而不是使用 setter。

我們得到了更少的重複和更高的可讀性，因為方法名稱揭示了之前被命令式程式碼（what）隱藏的意圖（why）。除其他好處外：

• 您可以透過以下方式測試您的域模型User.createAccount
• 需求的變化被本地化到一個單一的類（使用者）
• 實施起來仍然簡單快捷

• 控制器捕獲請求，將其分派到正確的服務並在傳送回之前格式化響應。
• 該服務接受請求，對其進行清理並執行。

大多數簡單的工作流都對此設定感到滿意。它是可測試的並且已充分分解。然而，這可能還不夠：訂閱新使用者所產生的副作用（例如傳送電子郵件、填寫 CRM ……）又如何呢？
有兩種處理方法：

• 同步地，在登入程式碼之後
• 與事件驅動架構非同步

我們很快就從事務指令碼轉到了事件驅動。至此，我們的需求已經滿足了，沒必要再深究了吧？
但不要忘記：我們在這裡談論的是 DDD。

交易事務邊界
除非我們正在處理事務邊界，否則我們不會談論下一步。
簡而言之，事務邊界封裝了必須持續更新的元素（關聯式資料庫中的行、NoSQL 資料庫中的文件等）。要麼事務作為一個整體成功，要麼回滾到之前的一致狀態（稱為Atomicity的特性，即[url=https://en.wikipedia.org/wiki/ACID]ACID[/url]中的 A ）
假設您正在管理一組使用者，並且您的程式碼將一個新使用者新增到該組中。您首先載入使用者組，確保您可以新增此使用者（例如，透過檢查該使用者不在該組中），然後新增它。
如果沒有事務邊界，當這個用例被同時呼叫多次時會出現很多問題。例如，在組中新增同一使用者的兩次呼叫可能會導致該組具有兩次相同的使用者。你可能不想要的東西。
透過事務邊界， 資料庫訪問層 (DAL)和資料庫本身採用一組複雜的技術來確保您一致地更新資料。 在此示例中，如果兩個事務對同一組進行操作，則第一個提交將成功，但第二個將失敗，因為資料庫檢測到更改發生在第二個提交之前，從而導致回滾。
這就是聚合發揮作用的地方。

聚合
最難掌握的概念之一（連同限界上下文）是聚合。但既然我們已經看到了事務邊界，就更容易理解聚合的需求了。
回到我們的例子，我們的服務將：

• 取一組
• 驗證我們要新增的使用者不在組中
• 將使用者新增到組

• 新增和刪​​除組的使用者
• 設定使用者數量限制
• 確保組中沒有兩次相同的使用者
• 以及其他業務定義的不變數。

• GroupUserAggregate是一個聚合，其中Group是根，這個聚合允許我們對管理組內的使用者進行操作
• UserAggregate是一個以User為根的聚合，你透過UserAggregate對單個使用者進行操作

• GroupUserAggregate管理組內的使用者並在組內執行規則（新增/刪除使用者，更改組名）
• UserAggregate管理使用者並圍繞使用者本身執行規則（例如更改名稱、電子郵件地址/密碼等）

架構模式
事情變得越來越複雜，我們的戰術工具集演變為：

• 一個控制器
• 一項服務
• 事件分發器
• 許多聚合體

• 事務指令碼只是實現你的行為的方法，沒有域封裝。您直接訪問資料庫（例如使用原始 SQL）
• Active Records將資料訪問抽象為代表資料庫中一行的物件
• 領域模型將行為封裝在具有代表業務的精確名稱和用例的類中（您不再使用 setter，而是使用清晰的域名）

• 事務指令碼最常透過出色的3 層架構（表示、業務、資料）實現。呼叫控制器的 UI/CLI 是表示層，控制器內部的程式碼是我們的業務層，我們的資料庫儲存資料層。
• Active Records也可以透過 3 層模式充分實現，但有些人喜歡使用4 層架構，在表示和業務之間新增一個應用程式（或服務）層。
• 域模型本身就是另一塊蛋糕，因為它經常與六角形架構一起使用（稱其為Clean、Onion等）。您的域變得越來越不瞭解實現細節（例如資料庫或第三方 API 呼叫），並且越來越依賴介面（透過神奇的控制反轉模式）。

限界上下文呢？

限界上下文就像 Monad。一旦你明白了，就很難向別人解釋。希望有界上下文不是內函子類別中的么半群。
甚至我自己也很難給出一個令人滿意的定義，而其他人提供的定義也無濟於事：

• 限界上下文是領域驅動設計的核心模式，Martin Fowler。
• 有界上下文只是應用特定域模型的域內的邊界，Microsoft。
• 有界上下文定義了某些子域適用性的有形邊界。這是一個特定子域有意義而其他子域沒有意義的區域。瓦迪姆薩莫欣。

• 目錄管理
• 存貨
• 訂購
• 支付
• 船運
• 支援

無處不在的語言
每個限界上下文都有一種通用語言：它是在每個限界上下文中工作的人們用來談論某事的語言：一個實體、一個事件、一個動作……
通常，當人們在Commerce Bounded Context中談論 Users 時，他們與Customer Management中的談論方式不同。

• 在 Commerce中，我們談論身份驗證機制、付款和送貨地址等。
• 在 CRM中，我們談論他從哪裡來，他買東西的頻率，它的滿意率等等。

但實際上，什麼是限界上下文？
到目前為止，我給出的是啟發式而不是定義。獲得這些知識後，理解限界上下文的定義可能會更容易。引用微軟：
有界上下文只是應用特定領域模型的領域內的邊界
就是這樣：Commerce 限界上下文中有關使用者的程式碼將不同於 CRM 限界上下文中的程式碼。

• 在 Commerce中，我們將有方法來驗證和建立帳戶、關聯支付資訊、傳送折扣券等。
• 在 CRM中，我們將有方法來獲取使用者、支付和訂單的歷史記錄、聯絡資訊（如果銷售代理聯絡過他）以及之前代理輸入的註釋的歷史記錄。

你說的領域模型？
啊，你終於注意到領域模型的使用了，對吧？在我們的示例中，我們有一個存在於我們域中的使用者實體。但是不同的元件將與使用者的不同部分進行互動：一些會談身份驗證，其他的個人資訊和其他支付歷史。這是同一使用者域實體上的 3 個不同的域模型。
領域模型只是對 Domain 的同一元素的不同檢視。六個盲人將以相同的方式觸控大象的不同部分。

子域
對於大型限界上下文，您有稱為子域的細分。在 Commerce 示例中，Inventory 和 Authentication 是兩個子域。每個子域都適合由單個團隊負責（工作分工的另一種啟發式）。
子域分為三類：核心、支援和通用。在定義它們之前，讓我們（再次）看一些啟發式方法。

• 核心：它們是您域的秘訣。他們處理對您的業務至關重要的職責和用例，使您的業務與眾不同並有助於實現利潤最大化的事情。
• 支援：那些是支援您的業務核心但不提供任何特定競爭優勢的子域。他們通常會解決顯而易見但不是很複雜的問題。
• 通用：它們是已經解決的明顯問題（由第三方或開源解決）。您的每個競爭對手或多或少都以相同的方式解決問題，不值得投入時間。

• 核心：您的核心子域是手錶製造。因為這就是您與競爭對手的區別：手錶的質量。您可能正在製作自己的手錶，因為這是您的秘方，或者讓製造商使用某種特殊配方為您製作。
• 支援：所有編目、庫存管理和訂購系統都是支援子域：它們不提供任何特定的競爭優勢，但它們支援公司的核心業務。它們專門與您的電子商務業務相關聯。您可以在內部解決它們，也可以外包。
• 通用：支付和身份驗證是眾所周知的，解決了大多數公司必須解決的問題。在內部實施它們沒有任何好處，而是由專門的實體實施。

• 商務BC：關於手錶是如何製造的知識以及證明它是頂級質量手錶的論據是商務的一部分
• 製造BC：製造手錶的知識以及如何確保其質量、透過控制和指揮各個部件都是製造過程的一部分。

總結​
我們只是觸及了表面。DDD 是一種非常龐大的方法論，涵蓋從戰略 規劃和分解（透過會議、事件風暴和所有爵士樂）到戰術 實施（模式、層次和邊界之間的通訊）。
問題區域非常密集和模糊：如何限制邊界，子域是什麼？它們是如何相互聯絡的？誰擁有什麼？沒有靈丹妙藥，需要經驗和成熟度才能擅長。
解決方案領域也非常大：有很多模式和工具、不同的層和架構可供選擇。我們幾乎沒有提到事件驅動架構、事件溯源和 CQRS。正確確定要使用的工具需要嚴謹和仔細的思考。
但是再一次。
不要讓任何人讓您認為沒有完整的 DDD 工具集就無法進行領域驅動設計。
您可以擁有一個跨越整個專案的限界上下文：它使事情更容易推理。
您可以在任何地方使用交易指令碼，獲得很好的效果，尤其是當您正在測試您的想法並且不確定它是否適合市場時。
隨著時間的推移，總是可以向您的專案中新增越來越多的領域驅動設計方法。所有增強都是漸進的。

結束語
最近，工匠精神已經在整個開發界掀起了一場風暴。越來越多的開發者熱衷於建立可長期維護的軟體。畢竟，我們大部分時間都在維護軟體，而不是編寫新程式碼。
這個領域很寬廣，因為有很多書籍和技術可以學習，以使我們在這個領域變得更好。領域驅動設計只是一個可以研究的地方，它可能是最深入和最難走的路。請記住，DDD決不是一個普遍的真理，只是一些人決定採用的觀點。
我相信它是一套很好的原則、實踐和工具。但不幸的是，學習曲線是非常陡峭的。
請帶著一點鹽來接受這些知識，在做任何事情之前，請根據你的需要來調整它。再一次，沒有銀彈。