工具與資源中心
幫助開發者更加高效的工作，提供圍繞開發者全生命週期的工具與資源
developer.aliyun.com/tool?spm=a1z3...
領域
領域與具體開發技術無關。就是你的軟體系統要解決的實際問題相關的所有東西的集合。
按問題域理解：每個限界上下文專注於解決某個特定的子域的問題，限界上下文可以理解為問題空間(Problem Space)，隨著設計和含義的清晰化，限界上下文會迅速的轉換為解決方案空間(Solution Space)
非常結構清晰的一張圖
領域的整體概念圖
限界上下文
限界上下文（Bounded context）是一個顯式邊界（邊界：通常是一個子系統或者一個特定團隊的工作），領域模型存在於邊界之內。建立模型過程中形成了通用語言，通用語言在特定上下文中才有明確的意義。
限界上下文書語義和語境上的邊界，用於表達其邊界內的軟體模型。在限界上下文內的軟體模型有著特定的含義並且在處理獨特的事務。
按團隊工作理解：一個團隊應該在一個限界上下文中工作，根據組織大小可能對應一個大部門也可能對應一個小團隊，如果是大部門，則小團隊圍繞著子域/聚合工作。
上下文對映圖
限界上下文之間會互相整合，這種整合關係稱為上下文對映
上下文對映圖不是一種企業架構，也不是系統拓撲圖，他是梳理限界上下文的重要手段，可以用upstream和downstream這種關係來形容，也可以用其他方式。
在DDD中存在多種組織模式和整合模式，如下。
1、 合作關係
2、共享核心
3、客戶方和供應方開發
4、遵奉者
5、防腐層， 簡稱ACL
6、開放主機服務，簡稱OHS
7、釋出語言,簡稱PL
8、另謀塔路
9、大泥球
待跟進——上下文對映設計工具，有必要學習和實踐
核心域
當限界上下文被當作組織的關鍵戰略決策進行開發和運維，則這部分軟體模型上核心域，核心域是當下或者未來一段時間企業的主航道，因為企業戰略不是一成不變的，核心域也是動態調整的。
核心域的識別是一個持續精煉的過程，從一堆混雜在一起的元件中提煉出最重要的內容。——舍九取一的能力
核心域雖然只是一個邏輯概念，但是它體現了重視度關注度，體現了資源的傾斜，架構設計中要清晰的識別出核心域，並確保在執行中能夠把最好的資源投入到核心域中。
子域
子域是領域更細粒度的劃分，根據重要性與功能將領域分為大致三類（視專案實際情況而定）的多個子域，分別是核心子域、支撐子域和通用子域。核心域是業務成功的主要促成因素，主要競爭力，支撐子域是支撐核心域的，而通用子域是業務系統的公用部分。
核心域
同上
支撐域
系統非核心業務，支撐性質的問題域
支撐子域不需要過度的考慮可擴充性和相容性，可重用性並非技術著力方向，可替代性才是，我們需要對支撐子域有著明確的契約規範和業務約束條件。
通用域
可以公共複用的問題域
領域模型
限界上下文是一個顯示的邊界，在邊界內部的軟體模型的表達就是領域模型，領域模型由模組、聚合、領域服務組成。
戰略設計
主要從業務視角出發，建立業務領域模型，劃分領域邊界，建立通用語言的限界上下文，限界上下文可以作為微服務設計的參考邊界。
領域設計的工作方式
在戰略層面，DDD非常強調針對業務問題的分析和分解，通過識別核心問題域來降低分析的複雜度。在戰術層面，DDD強調通過識別問題域裡的不同業務上下文來進行面向業務需求的元件化。最後在實現層面利用成熟的技術模式遮蔽掉技術細節的複雜度。
戰術設計
聚合
領域事件
領域服務
聚合根
聚合根是實體，有實體的特點，具有全域性唯一標識，有獨立的生命週期。一個聚合只有一個聚合根，聚合根在聚合內對實體和值物件採用直接物件引用的方式進行組織和協調，聚合根與聚合根之間通過 ID 關聯的方式實現聚合之間的協同。聚合根的主要目的是為了避免由於複雜資料模型缺少統一的業務規則控制，而導致聚合、實體之間資料不一致性的問題。首先它作為實體本身，擁有實體的屬性和業務行為，實現自身的業務邏輯。其次它作為聚合的管理者，在聚合內部負責協調實體和值物件按照固定的業務規則協同完成共同的業務邏輯。
實體
值物件
命令
命令（Command）：是執行者發起的操作，構成要件是執行者和行為
MVP(Minimun viable Product)
MVP(Minimum Viable Product),最小可行性產品,是研發新產品過程中常用的一個名詞,意指恰好滿足目標使用者核心需求的最簡形式產品。
BDD-行為驅動開發(behavior-driver-development)
行為驅動開發是一種敏捷軟體開發方法，它鼓勵軟體專案中的開發者、測試和業務人員之間的協作，包括驗收測試和客戶測試驅動等實踐。例項化需求(Specification by Example)也是一種用於定義軟體產品的需求和麵向業務的功能測試協作方法，它和行為驅動開發表達的是同樣的概念，採用的也是同樣的實踐。
行為驅動開發是在需求梳理階段對TDD測試驅動開發的響應，體現在測試驗收方面，驗收測試通常指面向業務(使用者)的(功能)測試，因此它還承載著限界需求說明和測試程式碼的職責。驗收測試最好使用業務人員、開發人員、測試人員都能理解的“語言”來描述，儘可能避免需求理解的偏差。在敏捷開發中，我們推薦使用使用者故事中的驗收條件來描述需求，採用自然語言和“假如/當/那麼”（Given/Wher/Then）的固定格式。
架構邊界清晰的好處之一是測試聚焦，讓測試聚焦某區域，某層次的測試而開展測試治理
- 動態變化，領域模型動態變化
- 主權意識的思考：領域設計強調領域的限界上下文內的主權意識，團隊要承擔起主權的捍衛者
- 軟體的模型會隨著業務的增長持續的打破邊界，走向混亂，持續的領域設計是在做混亂的治理，反熵增的，一套面向領域的軟體研發體系，大家按照領域獨立工作，並且對抗混亂，即系統可以自帶垃圾清理機制，增加系統的可持續性。
- 一個物件在不同的業務場景都用應用，在這種情況下，應當按業務場景(上下文)將物件分散其中，而不是用一個對接去貫穿所有業務場景。——這裡可能是領域設計與物件導向的區別，或者說領域設計是在業務邊界內的物件導向設計。見《領域設計精粹》23頁
- 邊界清晰的好處之一是測試聚焦，讓測試聚焦某區域，某層次的測試而開展測試治理
參考資料：
insights.thoughtworks.cn/tag/domai...
本文轉自：developer.aliyun.com/article/78867...
本作品採用《CC 協議》，轉載必須註明作者和本文連結