領域驅動設計與模式實戰(zhàn)

前言

構建企業(yè)應用程序并非易事。盡管我們擁有大量工具和框架來簡化這項任務，但仍然需要弄清楚如何更好地使用這些工具。大量方法可供我們選用，但關鍵是要知道在特定情況下應使用哪種方法，因為一種方法很難適用于所有情況。在過去幾年中，有一個社區(qū)逐漸成長起來，人們不斷尋找用于設計企業(yè)應用的方法，并以模式的形式將它們記錄下來（我整理了一份概述，在http：//martinfowler.com／articles／enterprisePattems.html站點上）。參與這項工作的人們（例如我）試圖找到公共方法，并描述如何更好地使用它們，以及它們何時適用。最后的結果過于寬泛，會導致為讀者提供了過多的選擇。當我開始創(chuàng)作Patterns Df Enterprise Application Architecture（《企業(yè)應用架構模式》，Addison.’Wesley公司2002出版）時，我曾在微軟技術方面尋找過這種類型的設計建議。幾經(jīng)努力之后幾乎一無所獲，只找到了一本討論此領域的書，就是Jimmy的前一本書。我喜歡他平易近人的寫作風格，也喜歡他深入挖掘易被他人忽略的概念的熱情。因此，Jimmy決定從我和企業(yè)模式社區(qū)中的其他人借鑒一些思想，并向讀者展示在編寫.NET應用程序時如何應用這些思想，我覺得再合適不過了。

內容概要

　　《領域驅動設計與模式實戰(zhàn)》全面詳細地解釋了領域驅動設計、測試驅動開發(fā)、依賴注入、持久化、重構、模式等很多基本概念，并以C#和.NET實例為依托，展示了這些概念的實際應用和重要價值。更重要的是，《領域驅動設計與模式實戰(zhàn)》還將這些概念整合到一起，為開發(fā)人員從頭至尾地揭示了完整的開發(fā)路線。閱讀《領域驅動設計與模式實戰(zhàn)》后，讀者將能真正掌握這些重要概念，并有效地將它們結合起來，應用到實際開發(fā)過程中?！　　额I域驅動設計與模式實戰(zhàn)》適合軟件架構師和開發(fā)人員閱讀。

作者簡介

作者：(瑞典)尼爾森(Jimmy Nilsson) 譯者：趙俐 馬燕新 等Jimmy Nilsson，資深軟件架構師，有超過20年從業(yè)經(jīng)驗，2008年在瑞典主要IT媒體評選的全國軟件架構師和開發(fā)人員排行榜上名列第2。目前擔任factor10咨詢公司CEO，客戶包括愛立信、微軟、沃爾沃等。本書是他的代表作，已被翻譯為日、俄等多種文字，他的另一部著作.NET Enterprise Design with Visual Basic .NET and SQL Server 2000也獲得Amazon 4星半評價。他的博客是http://JimmyNilsson.com/blog/。

書籍目錄

第一部分 背景知識第1章 應重視的價值，也是對過去幾年的沉重反思1.1 總體價值1.2 應重視的架構風格1.2.1 焦點之一：模型1.2.2 焦點之二：用例1.2.3 如果重視模型，就可以使用領域模型模式1.2.4 慎重處理數(shù)據(jù)庫1.2.5 領域模型與關系數(shù)據(jù)庫之間的阻抗失配1.2.6 謹慎處理分布式1.2.7 消息傳遞很重要1.3 對過程的各個組成部分的評價1.3.1 預先架構設計1.3.2 領域驅動設計1.3.3 測試驅動開發(fā)1.3.4 重構1.3.5 選擇一種還是選擇組合1.4 持續(xù)集成1.4.1 解決方案（或至少是正確方向上的一大步）1.4.2 從我的組織汲取的教訓1.4.3 更多信息1.5 不要忘記運行機制1.5.1 有關何時需要運行機制的一個例子1.5.2 運行機制的一些例子1.5.3 它不僅僅是我們的過錯1.6 小結第2章 模式起步2.1 模式概述2.1.1 為什么要學習模式2.1.2 在模式方面要注意哪些事情2.2 設計模式2.3 架構模式2.3.1 示例：層2.3.2 另一個示例：領域模型模式2.4 針對具體應用程序類型的設計模式2.5 領域模式2.6 小結第3章 TDD與重構3.1 TDD3.1.1 TDD流程3.1.2 演示3.1.3 設計效果3.1.4 問題3.1.5 下一個階段3.2 模擬和樁3.2.1 典型單元測試3.2.2 聲明獨立性3.2.3 處理困難因素3.2.4 用測試樁替換協(xié)作對象3.2.5 用模擬對象替換協(xié)作對象3.2.6 設計含義3.2.7 結論3.2.8 更多信息3.3 重構3.4 小結第二部分 應用DDD第4章 新的默認架構4.1 新的默認架構的基礎知識4.1.1 從以數(shù)據(jù)庫為中心過渡到以領域模型為中心4.1.2 進一步關注DDD4.1.3 根據(jù)DDD進行分層4.2 輪廓4.2.1 領域模型示例的問題/特性4.2.2 逐個處理特性4.2.3 到目前為止的領域模型4.3 初次嘗試將UI與領域模型掛接4.3.1 基本目標4.3.2 簡單UI的當前焦點4.3.3 為客戶列出訂單4.3.4 添加訂單4.3.5 剛才我們看到了什么4.4 另一個維度4.4.1 領域模型的位置4.4.2 孤立或共享的實例4.4.3 有狀態(tài)或無狀態(tài)領域模型實例化4.4.4 領域模型的完整實例化或子集實例化4.5 小結第5章 領域驅動設計進階5.1 通過簡單的TDD實驗來精化領域模型5.1.1 從Order和OrderFactory的創(chuàng)建開始5.1.2 一些領域邏輯5.1.3 第二個任務：OrderRepository+OrderNumber5.1.4 重建持久化的實體：如何從外部設置值5.1.5 獲取訂單列表5.1.6 該到討論實體的時候了5.1.7 再次回到流程上來5.1.8 總覽圖5.1.9 建立OrderRepository的偽實現(xiàn)5.1.10 簡單討論一下保存5.1.11 每個訂單的總量5.1.12 歷史客戶信息5.1.13 實例的生命周期5.1.14 訂單類型5.1.15 訂單的介紹人5.2 連貫接口5.3 小結第6章 準備基礎架構6.1 將POCO作為工作方式6.1.1 實體和值對象的PI6.1.2 是否使用PI6.1.3 運行時與編譯時PI6.1.4 PI實體/值對象的代價6.1.5 將PI用于存儲庫6.1.6 單組存儲庫的代價6.2 對保存場景的處理6.3 建立偽版本機制6.3.1 偽版本機制的更多特性6.3.2 偽版本的實現(xiàn)6.3.3 影響單元測試6.4 數(shù)據(jù)庫測試6.4.1 在每次測試之前重置數(shù)據(jù)庫6.4.2 在測試運行期間保持數(shù)據(jù)庫的狀態(tài)6.4.3 測試之前重置測試所使用的數(shù)據(jù)6.4.4 不要忘記不斷演變的模式6.4.5 分離單元測試和數(shù)據(jù)庫調用測試6.5 查詢6.5.1 單組查詢對象6.5.2 單組查詢對象的代價6.5.3 將查詢定位到哪里6.5.4 再次將聚合作為工具6.5.5 將規(guī)格用于查詢6.5.6 其他查詢選擇6.6 小結第7章 應用規(guī)則7.1 規(guī)則的分類7.2 規(guī)則的原則及用法7.2.1 雙向規(guī)則檢查：可選的（可能的）主動檢查，必需的（和自動的）被動檢查7.2.2 所有狀態(tài)（即使是錯誤狀態(tài)）都應該是可保存的7.2.3 規(guī)則應該高效使用7.2.4 規(guī)則應該是可配置的，以便添加自定義規(guī)則7.2.5 規(guī)則應與狀態(tài)放在一起7.2.6 規(guī)則應該具有很高的可測試性7.2.7 系統(tǒng)應阻止我們進入錯的狀態(tài)7.3 開始創(chuàng)建API7.3.1 上下文，上下文，還是上下文7.3.2 數(shù)據(jù)庫約束7.3.3 將規(guī)則綁定到與領域有關的轉換，還是綁定到與基礎架構有關的轉換7.3.4 精化原則：所有狀態(tài)，即使是錯誤狀態(tài)，都應該是可保存的7.4 與持久化有關的基本的規(guī)則API的需求7.4.1 回到已發(fā)現(xiàn)的API問題上7.4.2 問題是什么7.4.3 我們允許了不正確的轉換7.4.4 如果忘記檢查怎么辦7.5 關注與領域有關的規(guī)則7.5.1 需要合作的規(guī)則7.5.2 使用基于集合的處理方法7.5.3 基于服務的驗證7.5.4 在不應該轉換時嘗試轉換7.5.5 業(yè)務ID7.5.6 避免問題7.5.7 再次將聚合作為工具7.6 擴展API7.6.1 查詢用于設置UI的規(guī)則7.6.2 使注入規(guī)則成為可能7.7 對實現(xiàn)進行精化7.7.1 一個初步實現(xiàn)7.7.2 創(chuàng)建規(guī)則類，離開最不成熟的階段7.7.3 設置規(guī)則列表7.7.4 使用規(guī)則列表7.7.5 處理子列表7.7.6 一個API改進7.7.7 自定義7.7.8 為使用者提供元數(shù)據(jù)7.7.9 是否適合用模式來解決此問題7.7.10 復雜規(guī)則又是什么情況7.8 綁定到持久化抽象7.8.1 使驗證接口成為可插入的7.8.2 在保存方面實現(xiàn)被動驗證的替代解決方案7.8.3 重用映射元數(shù)據(jù)7.9 使用泛型和匿名方法7.10 其他人都做了什么7.11 小結第三部分 應用PoEAA第8章 用于持久化的基礎架構8.1 持久化基礎架構的需求8.2 將數(shù)據(jù)存儲到哪里8.2.1 RAM8.2.2 文件系統(tǒng)8.2.3 對象數(shù)據(jù)庫8.2.4 關系數(shù)據(jù)庫8.2.5 使用一個還是多個資源管理器8.2.6 其他因素8.2.7 選擇和前進8.3 方法8.3.1 自定義手工編碼8.3.2 自定義代碼的代碼生成8.3.3 元數(shù)據(jù)映射（對象關系（O/R）映射工具）8.3.4 再次選擇8.4 分類8.4.1 領域模型風格8.4.2 映射工具風格8.4.3 起點8.4.4 API焦點8.4.5 查詢風格8.4.6 高級數(shù)據(jù)庫支持8.4.7 其他功能8.5 另一個分類：基礎架構模式8.5.1 元數(shù)據(jù)映射：元數(shù)據(jù)的類型8.5.2 標識字段8.5.3 外鍵映射8.5.4 嵌入值8.5.5 繼承解決方案8.5.6 標識映射8.5.7 操作單元8.5.8 延遲加載/立即加載8.5.9 并發(fā)控制8.6 小結第9章 應用NHibernate9.1 為什么使用NHibernate9.2 NHibernate簡介9.2.1 準備9.2.2 一些映射元數(shù)據(jù)9.2.3 一個小的API示例9.2.4 事務9.3 持久化基礎架構的需求9.3.1 高級持久化透明9.3.2 持久化實體的生命周期所需的特定特性9.3.3 謹慎處理關系數(shù)據(jù)庫9.4 分類9.4.1 領域模型風格9.4.2 映射工具風格9.4.3 起點9.4.4 API焦點9.4.5 查詢語言風格9.4.6 高級數(shù)據(jù)庫支持9.4.7 其他功能9.5 另一種分類：基礎架構模式9.5.1 元數(shù)據(jù)映射：元數(shù)據(jù)類型9.5.2 標識字段9.5.3 外鍵映射9.5.4 嵌入值9.5.5 繼承解決方案9.5.6 標識映射9.5.7 操作單元9.5.8 延遲加載/立即加載9.5.9 并發(fā)性控制9.5.10 額外功能：驗證掛鉤9.6 NHibernate和DDD9.6.1 程序集概覽9.6.2 ISession和存儲庫9.6.3 ISession、存儲庫和事務9.6.4 得到了什么結果9.7 小結第四部分 下一步驟第10章 博采其他設計技術10.1 上下文為王10.1.1 層和分區(qū)10.1.2 分區(qū)的原因10.1.3 限界上下文10.1.4 限界上下文與分區(qū)有何關聯(lián)10.1.5 向上擴展DDD項目10.1.6 為什么對領域模型——SO分區(qū)10.2 SOA簡介10.2.1 什么是SOA10.2.2 為什么需要SOA10.2.3 SOA有什么不同10.2.4 什么是服務10.2.5 服務中包括什么10.2.6 深入分析4條原則10.2.7 再來看一下什么是服務10.2.8 OO在SOA中的定位10.2.9 客戶-服務器和SOA10.2.10 單向異步消息傳遞10.2.11 SOA如何提高可伸縮性10.2.12 SOA服務的設計10.2.13 服務之間如何交互10.2.14 SOA和不可用的服務10.2.15 復雜的消息傳遞處理10.2.16 服務的可伸縮性10.2.17 小結10.3 控制反轉和依賴注入10.3.1 任何對象都不是孤島10.3.2 工廠、注冊類和服務定位器10.3.3 構造方法依賴注入10.3.4 setter依賴注入10.3.5 控制反轉10.3.6 使用了Spring.NET框架的依賴注入10.3.7 利用PicoContainer.NET進行自動裝配10.3.8 嵌套容器10.3.9 服務定位器與依賴注入的比較10.3.10 小結10.4 面向方面編程10.4.1 熱門話題有哪些10.4.2 AOP術語定義10.4.3 .NET中的AOP10.4.4 小結10.5 小結第11章 關注UI11.1 提前結語11.2 模型-視圖-控制器模式11.2.1 示例：Joe的Shoe Shop程序11.2.2 通過適配器簡化視圖界面11.2.3 將控制器從視圖解耦11.2.4 將視圖和控制器結合起來11.2.5 是否值得使用MVC11.3 測試驅動的Web窗體11.3.1 背景11.3.2 一個示例11.3.3 領域模型11.3.4 GUI的TDD11.3.5 Web窗體實現(xiàn)11.3.6 小結11.3.7 用NMock創(chuàng)建模擬11.4 映射和包裝11.4.1 映射和包裝11.4.2 用表示模型來包裝領域模型11.4.3 將表示模型映射到領域模型11.4.4 管理關系11.4.5 狀態(tài)問題11.4.6 最后的想法11.5 小結11.6 結束語第五部分 附錄附錄A 其他領域模型風格附錄B 已討論的模式的目錄

章節(jié)摘錄

插圖：第一部分　背景知識第1章　應重視的價值，也是對過去幾年的沉重反思本章的目的是布置場景。本章將回顧過去幾年中我如何思考不同概念，以及我的思想是如何隨時間改變的。我們將圍繞很多話題討論并涵蓋大量基礎知識，但總體思想是討論在架構和開發(fā)過程方面應該重視的價值。 在這個過程中，我們將介紹并討論很多概念，本書后面將對這些概念進行深入討論。那么，讓我們開始吧！1.1 總體價值過去，我很擅長提前計劃。我經(jīng)常前瞻性地為項目添加功能、結構和機制。所添加的工件本身是非常好的，但我總是忘記它們從未發(fā)揮任何好的作用。當然，我也為項目增加了不少負擔。成本是相當高的，包括開發(fā)時間和增加的復雜性。在過去幾年中，我們被鼓勵使用另一種方法：“做可能管用的最簡單的事?！痹诤艽蟪潭壬?，這個思想來源于極限編程（ Extreme Programmin9，XP）運動[Beck xP]。另一種非常類似的說法是“你將不需要它”（ YouAren’tGoingtoNeedIt，YAGNI），這是幫助人們保持循規(guī)蹈矩的一種好方法。我猜想“保持簡單，傻瓜”（ Keep It Simple Stupid，KISS）也應屬于此類。這兩種方法（ 預先添加所有能想到的與做最簡單的事）是兩個極端，但我認為它們都忽略了某些事情，即沒有考慮到折中。正如所有關于“這個最好，還是那個最好”的問題一樣，答案是“它取決于什么條件”。這是一個有關折中的問題。我傾向于選擇這二者中間某個位置的方法，并根據(jù)情況選擇向哪個方向偏移。“l(fā)agom”這個詞是一個瑞典語單詞，它表示“剛剛好”或“不多也不少”這樣的意思。Lagom或“保持平衡”連同上下文敏感性就是我認為應該重視的總體價值，還有就是持續(xù)學習。讓我們更仔細地觀察一些更具體的價值領域（ 架構和過程組成），我們從架構開始，以便將我們引入正確的語境。

媒體關注與評論

“本書向讀者展示了如何將測試驅動設計、對象-關系映射和領域驅動設計等方法應用于.NET項目……書中介紹的技術在很多開發(fā)人員看來是未來軟件開發(fā)的關鍵……隨著技術越來越強大，復雜度越來越高，理解如何更好地使用技術也變得越來越重要。本書在推進這種理解方面邁出了可貴的一步?！薄　　狹artin Fowler，ThoughtWorks公司首席科學家，《重構》與《企業(yè)應用架構模式》作者“學習領域驅動設計的最好方法是坐在一位友好、耐心且經(jīng)驗豐富的從業(yè)者身邊，一步一步地共同研究問題。閱讀本書正是這種體驗。”　　——Eric Evans，領域驅動設計創(chuàng)始人

編輯推薦

《領域驅動設計與模式實戰(zhàn)》：.NET開發(fā)人員必讀之作，帶領讀者踏上領域驅動設計世界的實用、博學之旅。《企業(yè)應用架構模式》與《領域驅動設計》兩大名著精髓的實戰(zhàn)演練。不僅足夠詳細地解釋了基本思想，而且將一系列思想綜合到一起，幫助開發(fā)人員從頭到位了解整個路線。教你穿越業(yè)務層、數(shù)據(jù)層和UI層之間重重障礙，打通任督二脈。Martin Fowler和Eric Evans兩位大師聯(lián)袂推薦。模式、領域驅動設計和測試驅動開發(fā)賦予架構師和開發(fā)人員前所未有的能力。使他們能夠創(chuàng)建功能強大、健壯且可維護的系統(tǒng)。但是，如何在實際項目中充分發(fā)揮這些利器的潛力呢？《領域驅動設計與模式實戰(zhàn)》中，作者將Martin Fowler《企業(yè)應用架構模式》和Eric Evans《領域驅動設計》兩部經(jīng)典名著中的思想精髓以及重構、測試驅動開發(fā)等技術融會貫通，并通過大量C#實例加以闡釋，跨越了領域模型、數(shù)據(jù)庫與UI層之間的障礙。真實展示了創(chuàng)建高質量的企業(yè)級應用架構的全部過程。《領域驅動設計與模式實戰(zhàn)》就像是精彩紛呈的旅行見聞，每一處的所思所想都閃耀著智慧的光芒。生動詮釋了作者對面向對象開發(fā)中各種設計選擇的深刻理解。

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

    領域驅動設計與模式實戰(zhàn) PDF格式下載

---