close
文章出處
文章列表
Chapter 1 什么是DDD：
1、介紹領域驅動設計思想體系
和傳統開發方式比起來，領域驅動是一種新的軟件架構設計，它主要用來解決傳統開發中代碼雜亂無章，任意拼貼等最終導致程序難以維護而誕生的。
它提出軟件變得復雜和難以管理的主要原因是，領域復雜性和技術復雜性混合在了一起。
2、DDD如何管理復雜性
提煉問題重點、創建模型解決問題、使用公共語言建模協作、理解上下文關系。
DDD的側重點：核心領域、協作、與領域專家探討、復雜域模型的上下文理解。
3、DDD常見誤區
DDD是框架、DDD是靈丹妙藥
Chapter 2 提煉問題域：
1、知識提煉，領域知識的重要性
2、業務分析員，提煉知識是一個持續過程，每一次迭代，模型都會有所變化。
3、與領域專家一起獲得見解
4、使用BDD專注于應用程序的行為
Chapter 3 專注于核心領域：
1、找出核心，支撐和通用域
2、提煉有助于降低問題空間的復雜性
3、并非一個系統的所有部分都被精心設計
Chapter 4 模型驅動設計：
1、Code First模型驅動設計
2、使用該領域的通用語言來在代碼中描述，代碼是表述模型的主要形式，需要使用通用語言來約束它。
3、要讓團隊里面領域中隱含的觀念變得明確并賦予會組成共享通用語言的名稱。
4、通用語言應該用于測試，類名稱，和方法。
5、僅為核心領域應用模型驅動設計并創建UL才能帶來變化，不要將這些實踐應用到整個應用程序。
Chapter 5 領域模型實現模式：
1、領域層：是包含領域模型的代碼區域，他將領域模型的復雜性和應用程序偶發的技術復雜性隔離開來，負責確保基礎架構關注的是想管理事務和持久化這樣的問題，而不會摻入業務問題并卻不會讓領域中已經有的規則變模糊。
圖1、表示領域模型代碼僅構成整體代碼庫的一小部分
2、領域模型模式是基于沒有數據庫前提的，因此它可以演化并且以完全忽略持久化的方式來創建。
在設計領域模型時，不要從數據模型開始。相反要從代碼模型開始（Code First），與數據驅動設計相反的模型驅動。僅當必須考慮模型持久化時，才能在設計上做出讓步。模型內的領域對象成為普通老方C#對象（POCO）。這些類不再與基礎架構問題有關并卻完全忽略持久性。
3、事務腳本：事務腳本整個用例都是封裝在單個方法中，如數據檢索，持久化，事務管理，和業務邏輯。
事務腳本缺點：對于不知道面向對象的程序員來說是一種有幫助的模式，但是如果邏輯變得復雜，事務腳本會變得很難管理，事務腳本就會出現問題。
表模式：單個對象代表數據庫中的一個表或視圖，適合于數據庫驅動設計（DB First），不適合DDD。這個模式適合于領域中由有界上下文隔離的更簡單 部分以及簡單數據形式來說，非常合適并且比領域模型模式更易于掌握。但是如果對象模型和數據庫模型出現分歧，那么就需要朝著DDD模式的方向進行重構。
4、活動記錄：類似于表模式，是一種流行的模式，每個業務對象都負責其自身的持久化一起相關的業務邏輯，類似于Repository<T>。
5、貧血領域模型：又稱為反模式。違背了“只問不說”的原則，這個模式下領域服務會承擔代碼更具程序性風格的角色。貧血模型是DDD中一個良好開局。
Chapter 6 使用有界上下文維護領域模型的完整性：
1、大模型容易出錯，系統擴展越多，模型越復雜
2、使用有界上下文和破除大模型
3、有界上下文擁有從展現層到領域邏輯層，再到持久化，甚至到數據存儲功能的垂直切片。
并非所有的有界上下文都需共享相同的架構模式，如果有界上下文包含具有低邏輯復雜性的支撐或者通用域，那么可能會更傾向于使用CRUD的開發方式。
4、架構模式是在有界上下文的級別而非應用程序級別應用的，如果有界上下文沒有復雜的邏輯，則可以使用簡單的CRUD架構。
5、有界上下文中使用通用語言應該自主擁有從展現到領域邏輯，再到數據庫和結構的完整代碼堆棧。
Chapter 7 上下文映射：
1、上下文和上下文之間的耦合應該通過數據庫來集成并共享一個模型。
2、如果業務跨越許多上下文，并越過領域的各個部分。這個時候理解有誰負責每個需要變更的上下文以及這一變化如何發生很重要。
3、防止損壞層會在另外一個上下文交互時為模型提供隔離。該層會通過提供一個上下文到另一個上下文的轉譯來確保不損害完整性。
4、如果有界上下文的集成成本太高且沒有其他可用的非技術方法，那么應該遵循分道揚鑣方式。
Chapter 8 應用程序架構：
1、DDD架構必須支持的一項內容是保持領域邏輯的隔離性。
2、分層架構
3、依賴倒置
領域層不依賴任何層，所有依賴關系都是向內的，它通過委托給領域層來組織對用例的處理。
領域對象需要持久化，怎么才能依賴倒置呢？通常使用在應用層定義一個讓領域對象能夠融合切持久的接口。這個接口從應用層的角度編寫的。然后基礎架構層會實現并且適配這些接口。
4、領域層、應用程序服務層、基礎架構層
5、關于數據庫，應該有界上線文有自己的數據庫，而不是集成數據庫，就像在領域模型內一樣。這樣避免了客戶端代碼很容易繞過有界上下文的保護以及領域對象狀態的交互。
6、應用程序服務，定義和公開能力，業務用例寫作。應用程序服務表示的是用例，不是CRUD
作為實現詳情的領域層，領域服務方法可以揭示是否真的需要一個領域模型，如果發現所有業務都是CRUD，那么可以肯定，該領域缺乏所有真實的邏輯并且能通過使用事務腳本或者數據庫封裝模式來保持簡化。
文章列表
 |
不含病毒。www.avast.com |
全站熱搜
留言列表
