GitChat課程《領域驅動設計--戰(zhàn)略篇》筆記，課程作者張逸
一.領域驅動設計(Domain Driven Design, DDD)概述
1.DDD是一種針對大型復雜系統(tǒng)的領域建模與分析方法
- 改變了傳統(tǒng)軟件開發(fā)工程師針對數據庫進行的建模方法
- 將要解決的業(yè)務概念和業(yè)務規(guī)則轉換為軟件系統(tǒng)中的類型以及類型的屬性與行為
- 通過合理運用面向對象的封裝、繼承和多態(tài)等設計要素檀葛，降低或隱藏整個系統(tǒng)的業(yè)務復雜性立砸，提高系統(tǒng)的可擴展性
2.DDD是一套方法論酗宋，建立了以領域為核心驅動力的設計體系
- 傳統(tǒng)面向數據的建模方法是關系數據庫理論的延續(xù)患亿，關注數據表以及數據表之間關系的設計，這種設計方法面對日漸復雜的業(yè)務邏輯缺乏靈活性與可擴展性距境，也無法建立可重用、可擴展的代碼單元
- DDD具備開放性垮卓，可以使用不限于DDD提出的任何一種方法完成設計垫桂。例如，
1）使用用例(Use Case)扒接、測試驅動開發(fā)(TDD)伪货、用戶故事(User Story)對領域建立模型
2）使用整潔架構思想及六邊形架構建立層次分明们衙、結構清晰地系統(tǒng)架構
3）使用函數式編程思想，利用純函數與抽象代數結構不變性以及函數的組合性表達領域模型
3.DDD過程
- DDD當然不是架構方法碱呼，也并非設計模式蒙挑，而是一種思維方式，旨在加快開發(fā)處理復雜領域的軟件
- DDD是一個螺旋式的迭代設計過程愚臀，分為戰(zhàn)略設計階段和戰(zhàn)術設計階段
分析業(yè)務需求——提煉統(tǒng)一語言——建立領域模型——完成程序設計及編碼實現(xiàn)——重構
DDD過程
- 戰(zhàn)略設計階段
1）問題域：通過限界上下文(Bounded Context)和上下文映射(Context Map)對問題域進行合理的分解忆蚀，識別出核心領域(Core Domain)與子領域(SubDomain)，并確定領域的邊界以及領域間關系
2）架構：通過分層架構隔離關注點姑裂，將領域實現(xiàn)獨立出來馋袜；通過六邊形架構清晰地表達領域與技術基礎設施的邊界；通過CQRS模式分離查詢場景和命令場景 - 戰(zhàn)術設計階段
1）整個軟件系統(tǒng)被分解為多個限界上下文(或領域)后舶斧，就可以逐個進行戰(zhàn)術設計
2）領域驅動設計用以表示模型的主要要素包括：領域模型（值對象欣鳖、實體、領域服務茴厉、領域事件）泽台、資源庫（從存放資源的位置獲取、添加矾缓、刪除或者修改領域對象）怀酷、工廠(負責領域對象的創(chuàng)建，用于封裝復雜或者可能變化的創(chuàng)建邏輯）嗜闻、聚合(封裝一到多個實體與值對象蜕依，表示邊界，并維持邊界范圍之內的業(yè)務完整性）琉雳、應用服務
戰(zhàn)術設計諸要素之間的關系
- 演進的DDD過程
1）戰(zhàn)略設計會控制和分解戰(zhàn)術設計的邊界和粒度
2）戰(zhàn)術設計則以實證角度驗證領域模型的有效性样眠、完整性與一致性
3）戰(zhàn)術設計進而以演進的方式對之前的戰(zhàn)略設計階段進行迭代，形成螺旋式上升的迭代設計過程
DDD螺旋式上升的迭代設計過程
二.軟件復雜度
1.復雜系統(tǒng)
- 由大量相互作用的部分組成的系統(tǒng)
- 與整個系統(tǒng)相比咐吼，這些組成部分相對簡單吹缔，沒有中央控制，彼此之間也沒有全局性通訊
- 并且組成部分的相互作用導致了復雜行為
2.復雜系統(tǒng)理論
- 理解力維度：Simple/Complicated
影響因素：1）規(guī)模锯茄；2）結構 - 預測能力維度：Ordered/Complex/Chaotic
影響因素：變化(需求/第三方依賴)
3.控制軟件復雜度的原則
- KISS(Keep it Simple Stupid)原則
1）單一職責：每個程序只做一件事情厢塘，通過添加新特性而非修改舊系統(tǒng)去應對新需求
2）統(tǒng)一接口：每個程序的輸入輸出都是統(tǒng)一格式，A程序的輸出可以直接作為B程序的輸入肌幽，以支持程序之間的自由組合 - 清晰與一致的結構
1）整潔架構：無需依賴于任何基礎設施就可以對它進行測試晚碾，只需通過邊界對象發(fā)送和接收對應的數據結構即可
2）穩(wěn)定依賴原則：整潔架構遵循穩(wěn)定依賴原則，不對變化或易于變化的事物形成依賴 - 擁抱變化
1）可進化性(Evolvability)：通過劃分設計單元的邊界喂急，保證邊界內的單元實現(xiàn)細節(jié)不會影響到外部的其他設計單元格嘁，從而可以容易地替換單元內部的實現(xiàn)細節(jié)
2）可擴展性(Extensibility)：通過封裝處理軟件系統(tǒng)中的變化點(熱點)，以隔離變化廊移、降低耦合
3）可定制性(Customizability)：通過引入元數據和使用插件模式滿足定制化要求
三.DDD對軟件復雜度的應對
1.需求引起的軟件復雜度
- 需求分為業(yè)務需求與質量屬性需求糕簿，因此需求引起的復雜度可分為技術復雜度和業(yè)務復雜度
- 技術復雜度
技術的復雜度來自需求的質量屬性探入，諸如安全、高性能懂诗、高并發(fā)蜂嗽、高可用等相互影響甚至矛盾的因素 - 業(yè)務復雜度
業(yè)務復雜度對應了客戶的業(yè)務需求，業(yè)務復雜度隨需求規(guī)模的增大而增加殃恒。規(guī)模擴大不僅增加產生功能的數量植旧，還因為功能的相互依賴增大業(yè)務復雜度 - 軟件技術復雜度與業(yè)務復雜度的疊加，包括
1）軟件系統(tǒng)的規(guī)模方面：問題域過于龐大而復雜离唐，使得從問題域中尋求解決方案的挑戰(zhàn)增加
2）軟件系統(tǒng)的結構方面：開發(fā)人員將業(yè)務邏輯的復雜度與技術實現(xiàn)的復雜度混淆在一起
3）軟件系統(tǒng)的變化方面：隨需求的增長和變化病附，無法控制業(yè)務復雜度和技術復雜度
2.DDD對軟件復雜度的應對措施1：隔離業(yè)務復雜度與技術復雜度
- 確定業(yè)務邏輯與技術實現(xiàn)的邊界，從而隔離各自的復雜度
1）理想狀態(tài)下亥鬓，業(yè)務規(guī)則與技術實現(xiàn)是正交的完沪，無論使用何種技術，只要業(yè)務需求不變嵌戈，業(yè)務規(guī)則就不會發(fā)生變化
2）DDD通過分層架構與六邊形架構隔離業(yè)務邏輯與技術實現(xiàn) - 分層架構的關注點分離
1）領域層(Domain Layer):業(yè)務邏輯的關注點
2）基礎設施層(Infrastructure Layer):支撐業(yè)務邏輯的技術實現(xiàn)
3）應用層(Application Layer):作為業(yè)務邏輯的外觀丽焊，暴露能體現(xiàn)業(yè)務用例的應用服務接口；同時作為業(yè)務邏輯與技術實現(xiàn)的粘合劑咕别，實現(xiàn)二者的協(xié)作
DDD分層架構
- 六邊形架構的內外分離
應用層與領域層處于六邊形架構的內核，并通過六邊形邊界與基礎設施層隔離
DDD的六邊形架構
3.DDD對軟件復雜度的應對措施2：限界上下文的分而治之
- 在通過分層架構和六邊形架構對軟件系統(tǒng)進行邏輯劃分的同時写穴，通過限界上下文垂直分割業(yè)務惰拱，將龐大的軟件系統(tǒng)劃分為多個松散耦合的小系統(tǒng)，從而限制了每個小系統(tǒng)的業(yè)務復雜度和技術復雜度
4.DDD對軟件復雜度的應對措施3：領域模型對領域知識的抽象
- 領域模型是對業(yè)務需求的抽象啊送，表達了領域概念偿短、領域規(guī)則以及領域概念之間的關系
- 領域模型是對統(tǒng)一語言的可視化表示，減少需求溝通可能出現(xiàn)的歧義馋没，簡化領域邏輯
