領域驅動設計 (DDD) 簡介 - jannikwempe

DDD 上下文中的域是什麼？
一種知識、影響或活動的範圍。
我將向您概述 DDD 的全部內容。這篇文章是關於“為什麼？” 和“什麼？” 的 DDD。我不會在這裡深入探討特定主題。儘管如此，我還是會指出一些重要術語的定義，就像我剛剛對“域”所做的那樣。正如您將意識到的，共享詞彙也是 DDD 本身的一部分。
 

今天 DDD 還有用嗎？
DDD 不是關於某種技術，它是一個更現代的概念。Sam Newman 所著的《構建微服務》一書第一頁的快速引用：

Eric Evan 的書 DDD 幫助我們理解了在我們的程式碼中表示現實世界的重要性。並向我們​​展示了更好的方法來為我們的系統建模。
此外，IBM Garage Event-Driven Reference Architecture有一章關於方法論 DDD。
回答有關相關性的問題：直到今天，它確實非常有效。隨著最新的進展，讓我們繼續探索“為什麼？” 和“什麼？”
  

為什麼會存在 DDD？
為什麼甚至需要像 DDD 這樣的東西？Eric Evans 書的副標題提供了一個非常好的提示：

解決軟體核心的複雜性
通常，軟體專案的關鍵複雜性在於領域本身。您無法更改領域內的複雜性。您可以嘗試在銀行櫃檯告訴客戶，您只只專注於支付，而不是貸款業務，因為它太複雜了。
此外，我們不只是為了開發軟體而開發軟體。我們這樣做是為了解決問題和改進事情：

軟體的核心是為使用者解決領域相關問題的能力。所有其他功能，儘管它們可能很重要，但都支援這個基本目的。
 

DDD 是什麼？
那麼究竟什麼是 DDD？DDD 不能用一兩句話來定義。它是一種開發由多個拼圖組成的複雜軟體的方法：

1. 集中在核心的複雜性和機會領域。
2. 與領域專家和軟體專家合作探索模型。
3. 在有限的上下文中說一種無處不在的語言。

專注領域
集中在核心的複雜性和機會領域。
核心複雜性和機會可能不同於我們所說的“業務”。想想推特：提供推文的功能、相互關注等並不是主要的複雜性。很可能主要的複雜性在於擴充套件該平臺。
 

探索模型
與領域專家和軟體專家合作探索模型。
模型是處理上述複雜性的一種方式。但是，首先，什麼是模型？
 DDD 上下文中的模型是什麼？

一個抽象系統，描述域的選定方面並可用於解決與該域相關的問題。
描述該術語的另一種方式（也來自埃裡克·埃文斯本人）：

模型是一種簡化。它是對現實的一種解釋，它抽象了與解決手頭問題相關的方面並忽略了無關的細節。
它不是圖表（因此也不是實體關係圖（ERD）——儘管實體也是 DDD 中使用的一個術語）。圖表只是幫助傳達模型。您會在 DDD 的上下文中看到很多圖表。沒有特定的、唯一的建模語言。大多數情況下，使用一些類似 UML 的圖表或只是手寫草圖。這不是關於圖表，而是關於它背後的概念。
動詞“探索”是故意選擇的，而不是像“寫下來”這樣的詞語。獲得模型將是一個迭代過程。沒有一勞永逸地完成模型這樣的事情。將有新的見解、新的或不斷變化的問題出現在該領域或其他任何方面。這是一個持續的探索。
 

案例：模型示例
想想典型的世界地圖（有點像圖表）。世界標準地圖顯示的是墨卡託投影。你們中的大多數人都知道這張地圖不是關於不同國家的大小或類似的東西。它是專門為海上航行而建立的。您可以在地圖上的點之間畫一條線，並知道如何使用指南針導航。
這是地圖後面的實際模型：

Eric Evans 在他 2019 年的會議演講中使用的這個例子是一個很好的例子。它指出模型與手頭的問題直接相關。
 擁有模型實際上並沒有給你任何優勢。優勢並非來自擁有模型。優勢來自於擁有一個非常適合您要解決的特定問題集的模型。
模型必須在“領域專家和軟體專家的合作”中進行探索。領域專家建立模型和開發人員都不會將他們的 ERD 作為模型出售。協作探索模型的過程被 Eric Evans 稱為“Knowledge Crunching”。
最後用 Eric Evans 的兩句話來表達最重要的一點來結束本節：

本書的主旨是一個模型應該強調實施、設計和團隊溝通。為這些不同的目的使用不同的模型會帶來危險。

如果編寫程式碼的人不覺得對模型負責，或者不瞭解如何使模型為應用程式工作，那麼模型與軟體無關。如果開發人員沒有意識到更改程式碼會改變模型，那麼他們的重構將削弱模型而不是加強模型。
這些要點是：程式碼和模型直接相關。
 

說一種無處不在的語言

在有限的上下文中說一種無處不在的語言。
在 DDD 的上下文中，無處不在的語言是什麼意思？

一種圍繞領域模型構建的語言，供所有團隊成員 在有界上下文中使用，以將團隊的所有活動與軟體聯絡起來。
其中還有一個值得定義的術語：有界上下文：

上下文： 單詞或語句出現的語境決定了其含義。 關於模型的陳述只能在上下文中理解。

有界上下文：對邊界（通常是子系統或特定團隊的工作）的描述，在該邊界內定義和適用特定模型。

值得注意的是，“無處不在”的語言在適用於系統範圍的意義上並不是無處不在的。而是在程式碼、語音、圖表等中使用。這也是新增“在有界上下文中”限制的原因。該語言將適用於您必須明確定義的邊界。這不是跨界定義術語，例如為整個公司定義術語。例如，在營銷或倉庫環境中，甚至可能在倉庫環境的不同部分，使相同東西可能非常不同。

用我自己的話來說：泛在語言是一種與給定領域模型直接互連的通用語言，它在您定義的邊界內隨處使用。“與模型直接互連”的部分揭示了語言的變化也應該與模型的變化直接相關。事實上，模型應該使用領域專家已經使用過的術語來建立。

[...] 語言的更改將被識別為域模型的更改，並將引導團隊更新類圖並重新命名程式碼中的類和方法 [...] 使用模型作為語言的支柱。[...] 在圖表、寫作，尤其是演講中使用相同的語言。
太好了，現在我們知道這個詞是什麼意思了，但為什麼這很重要？本書的這一部分給出了原因的印象：

在沒有通用語言的專案中，開發人員必須為領域專家翻譯。領域專家在開發人員和其他領域專家之間進行翻譯。開發人員甚至可以互相翻譯。
我敢打賭，您遇到過這樣的情況，您作為開發人員不知道領域專家在說什麼，甚至更糟的是，您認為自己知道但他/她在談論其他事情。反過來也是一樣。
使團隊習慣於詢問所使用的特定術語的含義。團隊必須在所有溝通中堅持使用無處不在的語言。領域專家正在談論給定領域中未反映在模型中的概念？模型可能不完整。
無處不在的語言將導致程式碼和實際領域更接近。它不僅與反映實際領域的程式碼有關，它還具有許多其他積極方面。考慮程式碼的可維護性。如果另一位開發人員在一段時間後返回程式碼，則會在域中使用術語。領域專家確實瞭解所使用的術語，他們不僅僅是具有由開發人員組成的名稱的類。
 

結論
DDD 仍然是您工具箱中的一個重要概念。它已經影響了許多其他領域（檢視 JPA 規範的 JavaDoc）並且仍在影響它們。
解決領域的問題是開發軟體的全部意義所在。我們必須處理這種複雜性。但是我們可以透過應用 DDD 來處理這種複雜性，從而使我們的生活更輕鬆。