所有的計算都表明它不工作，唯一的做法是：使其工作。 ——Pierre-Georges Latécoère早期法國航空企業(yè)家
　　是的，我們將使其工作。然而，在軟件開發(fā)過程中采用領域驅動設計卻是困難的。即便是有能力的開發(fā)者，也很難找到實現領域驅動設計的正確方法。
　　起飛，著陸
　　在我小的時候，我的父親學習過駕駛小型飛機。我們經常會全家出去飛行，有時會飛到另一個機場，在那里吃過午飯后再返回。當父親時間有限而他依然想飛時，父親便帶上我一起在機場上空盤旋，起飛，著陸，再起飛，再著陸。
　　也會有些長途飛行，這時我們會帶上一張由父親先前繪制好的路線圖。我們幾個小孩便當起了領航員：將圖上的標志對應著陸地上的地標，以確保我們沒有跑偏航線。這是一件很有趣的事情，因為要識別遠在地面上的物體是很有挑戰(zhàn)性的。事實上，我敢肯定父親根本不用我們領航便知道我們處于什么方位——他能看到儀表盤上的所有信息，并且他擁有儀表飛行執(zhí)照。
　　空中的景觀的確改變了我的視野。不時地，父親和我會飛過我們鄉(xiāng)下的房子。在幾百英尺的高空中，我體會到了另一種“家”的概念，而這在之前是沒有過的。當我們飛過自家的房子時，母親和我的姐妹們便會跑到院子里向我們揮手。我知道那是她們，即便我看不清楚她們是誰。談話肯定是不行的，連大聲喊都不行，她們是聽不見的。我還可以看到將我家和外面公路分開的護欄，平時我們會像走平衡木一樣在護欄上面走來走去。從空中看，它們就像被細心編排過的小樹枝一樣。我們
　　家的院子很大，每每到了夏天，我都會開著割草機一排一排地修理院子里的草坪。而在空中時，我只能看到一片綠色，小草的葉子肯定是看不清楚的。
　　我喜歡在空中的時刻，直到現在我還不時回想起這些時刻，好像那個降落飛
　　機的黃昏就發(fā)生在不久以前一樣。雖然如此，在地面上的感覺依然是無法取代的，
　　因為它給我一種腳踏實地的感覺。
　　著陸于領域驅動設計
　　一開始接觸領域驅動設計（ DDD）就像一個小孩之于飛行一樣。天空中的景色是令人驚嘆的，但有時我們卻因為過于陌生而搞不明白它們到底是什么。要從甲地到乙地顯得如此的遙遠。然而， DDD的“成年人 ”們卻總知道他們所處的方位，因為他們在很早之前便繪制好了路線圖，并且能夠完全按照儀表進行相應的操作。而還有很多人找不到“在地面上”的感覺，此時我們需要的是“穩(wěn)定著陸”的能力，然后找到一張地圖給我們指引方向。
　　Eric Evans的《領域驅動設計：軟件核心復雜性應對之道》是一本經得住時間考驗的經典之作。我堅定地相信，在接下來的幾十年里，本書依然會是開發(fā)者的實用指導。和其他模式一樣，該書為我們建立起了一種高屋建瓴式的寬闊視野。然而，對于如何實現 DDD，我們可能將面對更多的挑戰(zhàn)。通常來說，我們更渴望看到一些具體的例子。
　　我的目標之一便是幫助你來一個“軟著陸”，保全飛機，然后沿著一條周知的線路帶你回家。這將幫助你如何更好地去實現 DDD，并且通過你所熟悉的工具和技術給出示例演示。當然，任何一個人都不可能一直呆在家里，所以我還會帶領你到新的地帶去冒險，這些地帶你可能從來沒有去過。冒險之路是險峻的，但是在正確的戰(zhàn)術應對下，征服這些困難是可能的。在這條冒險之路上，你將學到另外的架構和模式來集成多個領域模型。你將接觸到先前沒有被研究過的集成方法，并且學到如何開發(fā)自治性服務。
　　我將向你提供一張對短途旅行和長途旅行均適用的地圖，它可以幫助你更好地享受沿途風景，同時又不至于迷失途中。
　　對照地形，繪制飛行圖
　　在軟件開發(fā)的過程中，我們經常做的一件事便是將一種東西映射到另一種東西。我們將對象映射到數據庫，映射到用戶界面，或者映射到不同的應用層展現（包括作為消費方的其他系統(tǒng)或應用程序）。在所有這些映射中，我們很自然地希望在Evans提出的高層模式和具體實現之間存在一種映射。
　　即便你已經接觸過 DDD，你依然有很多可以獲益的地方。有時， DDD首先被看作是一套技術工具集，有人將此稱為 DDD-Lite。我們可能已經對實體、服務等 DDD概念非常熟悉了，并且大膽地嘗試著設計聚合，還通過資源庫來管理持久化。這些模式是大家相對熟知的，使用起來很容易，我們甚至還使用了值對象。以上這些都屬于戰(zhàn)術設計模式范疇，也即更加偏向技術層面。這些模式可以很好地幫我們解決軟件問題。而同時，對于戰(zhàn)術性模式，我們依然有許多需要學習的。我將戰(zhàn)術模式映射到實現層面。
　　你曾了解過戰(zhàn)術建模之外的東西嗎？你曾了解過被稱為 DDD“另一半”的戰(zhàn)略設計模式嗎？如果你還沒有使用過限界上下文和上下文映射圖，那么你很有可能也沒有使用過通用語言。
　　如果說 Evans在軟件開發(fā)社區(qū)有一項發(fā)明，那便是通用語言。通用語言是一種團隊協(xié)作模式，用于捕捉特定業(yè)務領域中的概念和術語。一個特定領域的軟件模型通過不同的名詞、形容詞和動詞來表達，這些詞匯是開發(fā)團隊正式使用的，而團隊中應該包含一個或多個領域專家。然而，將通用語言僅限定于一些詞匯則是錯誤的。就像自然語言反映人們的思想一樣， DDD的通用語言反映了領域專家對于軟件系統(tǒng)的思維模型。通用語言和那些戰(zhàn)略和戰(zhàn)術性的建模模式同等重要，在有些情況下甚至更具有持久性。
　　簡單地講， DDD-Lite將導致劣質的領域對象，因為通用語言、限界上下文和上下文映射圖的作用太大了，你從其中獲得的并不只是一套團隊共用的語言。在限界上下文中用通用語言來表述一個領域模型可以增加業(yè)務價值，并且使我們確信所開發(fā)軟件的正確性。即使從技術的角度，它也可以幫助我們創(chuàng)建更好的領域模型，這樣的模型行為豐滿，業(yè)務純凈，并且可以減少犯錯誤的可能性。因此，我將戰(zhàn)略設計模式映射到了可理解的實際例子中。
　　本書對于 DDD的映射可以幫助你同時體會到戰(zhàn)略設計和戰(zhàn)術設計的好處。通過一些具體的例子，你將感受到這些 DDD映射的業(yè)務價值和技術展現力。
　　如果我們對于 DDD的所有實踐都只是停留在“地面上”，那將是令人失望的。過度地拘泥于細節(jié)將使我們喪失在空中俯瞰的機會。所以，不要將自己局限在地面的細節(jié)上，要勇敢地飛翔在空中，居高臨下。搭上戰(zhàn)略設計的航班，去了解限界上下文和上下文映射圖，你將獲得更廣闊的視野。當你從 DDD的航班中獲益時，我的目的也就達到了。
　　各章概要
　　以下是各章的主要內容以及你將如何從中獲益。
　　第1章：DDD入門
　　本章向你介紹 DDD的好處，并且教你如何盡可能多地去實現 DDD。你將學到當你在應對復雜的軟件系統(tǒng)時， DDD可以為你的項目和團隊帶來什么。同時，你將了解到通常的 DDD替代方案以及這些方案為什么會導致問題。作為對 DDD的基礎講解，本章將教你如何在項目中開始采用 DDD，還有如何向你的領域專家和技術團隊推銷 DDD。在DDD的武裝下，你將學會如何迎接挑戰(zhàn)，勇往直前。
　　本章將介紹關于一個公司及其團隊的案例研究，雖然該公司是虛構的，但是他們所面臨的 DDD挑戰(zhàn)卻是真實存在的。該公司旨在開發(fā)一個新的多租戶 SaaS（Software as a Service，軟件即服務）軟件產品。不出所料，在使用 DDD時，他們犯了一些常見的錯誤。不過還好，他們發(fā)現了這些錯誤，并解決了一些問題，因此項目還算沒有偏離正軌。該團隊需要開發(fā)一套基于 Scrum的項目管理軟件。該案例還會在本書的后續(xù)章節(jié)中連續(xù)講到。每一種戰(zhàn)略和戰(zhàn)術模式都將教給這個團隊。在這個過程中，團隊有誤入歧途的時候，但最終他們將向著成功的 DDD實踐昂首闊步。
　　第2章：領域、子域和限界上下文
　　領域、子域和核心域分別是什么？限界上下文是什么，我們?yōu)槭裁匆�使用它，并且如何使用？這些問題將在這個 SaaS項目團隊犯錯誤的時候給予解答。在他們的第一個 DDD項目中，他們并不了解子域、限界上下文和通用語言這些概念。事實上，他們根本不知道什么是戰(zhàn)略設計，只是采用了戰(zhàn)術設計來解決一些技術問題。這樣他們在開始設計領域模型的時候便遇到了不少問題。幸運的是，他們及時地意識到了這些問題，項目還有挽回的余地。
　　本章還講到了如何使用限界上下文對模型進行分離，這是非常重要的；同時還講到了一些模型分離不當的反例，并且給出了有效的實現建議。在采用了這些建議之后，該團隊的成員們重新創(chuàng)建了兩個不同的限界上下文。這種合理的模型分離帶來的好處是引出了第三個限界上下文——核心域，這將是本書使用的主要例子。
　　對于那些苦于單單從技術層面應用 DDD的人來說，本章應該能引起你的共鳴。如果你還是 DDD戰(zhàn)略設計的外行，那么本章將為你指明方向。
　　第 3章：上下文映射圖
　　上下文映射圖幫助我們理解業(yè)務領域、模型間的邊界，以及這些模型之間的集成方式。
　　上下文映射圖絕對不只是繪制系統(tǒng)架構圖這么簡單，它處理的是不同限界上下文之間的關系，以及如何在不同的模型之間映射對象。對于在復雜的業(yè)務系統(tǒng)中使用好限界上下文，這是至關重要的。在第 2章中，團隊成員們在首次嘗試限界上下文時碰到了問題。本章中，他們將學著如何利用上下文映射圖來解決這些問題。這樣的結果是產生了兩個體面的限界上下文，這兩個上下文將被另外一個負責核心域的團隊所使用。
　　第 4章：架構
　　我們都知道分層架構，但它是開發(fā) DDD軟件的唯一方式嗎，也或許還存在另外的方式？在本章中，我們將講到：六邊形架構（端口和適配器）、面向服務架構、REST、CQRS、事件驅動（管道和過濾器，長時處理過程，事件源）和數據網格，其中好幾種架構都將被該團隊成員所采用。
　　第 5章：實體
　　在DDD的戰(zhàn)術模式中，我們將首先講到實體。團隊成員們一開始過于強調實體的作用而忽視了值對象。受到數據庫和持久化框架的影響，實體被該團隊濫用了，此時他們開始討論如何避免大范圍地使用實體。
　　在本章中，你將看到很多優(yōu)秀的實體設計例子。同時，本章還將講到如何使用實體來表達通用語言，以及如何對實體進行測試、實現和持久化。
　　第 6章：值對象
　　早些時候，團隊成員們錯過了采用值對象的好機會。他們過于注重為實體創(chuàng)建一些單一的屬性，這種方式是欠妥的，更好的方式是將這些單一的屬性聚合成一個不變的整體。本章將從不同的角度講解如何設計值對象，以及在什么時候采用值對象會優(yōu)于實體。同時，本章還包含了一些其他話題，比如值對象在集成中的角色和對標準類型的建模等。然后，本章講到了如何設計以領域為中心的測試，如何實現值對象。此外，本章還講到了在聚合中存儲值對象時，如何避免持久化機制所帶來的不利影響。
　　第 7章：領域服務
　　本章將講到，在領域模型中，什么時候應該將一個概念建模成粒度適中，并且無狀態(tài)的領域服務。你將學到何時應該使用領域服務而不是實體或值對象，以及如何使用領域服務來處理業(yè)務邏輯和技術上的集成。團隊成員們向我們展示了何時應該使用領域服務，以及如何設計領域服務。
　　第 8章：領域事件
　　Eric Evans并沒有在他的書中正式介紹領域事件，領域事件是在他那本書出版之后才進入人們視野的。在本章中，你將學到為什么領域事件如此有用，以及使用領域事件的不同方法。領域事件甚至被用來輔助集成和自治性服務。在軟件系統(tǒng)中，我們經常使用一些技術層面的事件機制，但本章將著重講解領域事件與這些事件機制的區(qū)別。本章還將指導你如何設計并實現領域事件，包括一些可行的方案和對這些方案的權衡選擇。然后，本章將講到如何創(chuàng)建一個發(fā)布 -訂閱機制；如何利用事件來集成整個企業(yè)軟件中的各個訂閱方；如何創(chuàng)建和管理事件存儲；如何處理消息機制所面臨的常見挑戰(zhàn)等。
　　第 9章：模塊
　　對于模型中的對象，我們應該如何將他們組織在大小適中的容器中呢？我們又如何保證不同容器中的對象之間只存在有限的耦合？另外，我們如何對這些容器進行命名以體現通用語言？除了包和命名空間之外，我們如何使用由語言和框架提供的現代模塊化機制，比如 OSGi和Jigsaw？在本章中，你將看到 SaaS團隊成員是如何在不同的項目中使用模塊的。
　　第 10章：聚合
　　在DDD的戰(zhàn)術模式中，聚合可能是最不容易理解的了。然而，在遵循一定的經驗法則的情況下，我們是能夠更簡單、更快地實現聚合的。在本章中你將學到：如何利用聚合在不同的小規(guī)模對象集群間創(chuàng)建一致性邊界，從而降低模型的復雜性。由于在細枝末節(jié)上花了太多精力， SaaS團隊成員們在設計聚合時總是磕磕絆絆。我們將仔細研究該團隊所面臨的挑戰(zhàn)，并且分析錯誤的原因以及他們的應對策略。結果，團隊成員們對他們的核心域有了更深層次的理解。我們將看到，在合理的事務處理和保證最終一致性（Eventual Consistency）的前提下，該團隊更正了他們所犯的錯誤，并且在一個分布式環(huán)境中設計出了更具有伸縮性和更高效的模型。
　　第 11章：工廠
　　工廠已經在 [Gamma et al.]中被大量地談及了，為什么還要講呢？本章并不打算重蹈覆轍，而是將重點放在“工廠應該存在于何處”這個問題上。在本章中，我們將講到在 DDD中實現工廠的技巧。團隊成員在他們的核心域中創(chuàng)建的工廠可以簡化客戶端接口，并且對模型的消費方起到保護作用，從而避免了在多租戶環(huán)境中引入災難性的 bug。
　　第 12章：資源庫
　　資源庫只是一個數據訪問對象（ Data Access Object, DAO）嗎？如果不是，它們之間有什么區(qū)別呢？我們?yōu)槭裁磻�該將資源庫看成是對集合的模擬而非數據庫呢？在本章中，我們將講到如何利用 ORM來實現資源庫，其中有兩種 ORM方案，一種采用基于網格的分布式緩存，另一種則采用 NoSQL的鍵值對存儲。團隊成員們可以采用任何一種作為他們的持久化機制。
　　第 13章：集成限界上下文
　　到現在為止，你已經了解了戰(zhàn)略層次的上下文映射圖和多種戰(zhàn)術層次的模式。本章將講到，在 DDD中，我們如何通過上下文映射圖來集成不同的模型。在團隊對核心域和其他輔助性的限界上下文進行集成時，我們將給出相應的建議和指導。
　　第14章：應用程序
　　對于每一個核心域的通用語言，我們都設計了相應的模型，并且進行了足夠的測試，模型工作正常。然而，客戶應該如何使用我們的模型呢？他們應該使用 DTO將數據在模型和用戶界面之間傳輸嗎？或者存在其他方案可以實現模型和展現組件間的數據傳遞？ DDD中的應用服務和基礎設施是如何工作的？對于這些問題，本章都將做出解答。
　　附錄A：聚合與事件源： A+ES
　　事件源是一種持久化聚合的重要技術，同時也是事件驅動架構的基礎。事件源通過一系列的事件來表示聚合的所有狀態(tài)。通過有序的事件重放，我們可以重新構建聚合的狀態(tài)。當然，使用事件源的前提是：它能夠簡化對數據的持久化，并且能夠捕捉到那些具有復雜行為屬性的概念。
　　Java和開發(fā)工具
　　本書中的絕大多數例子都是使用 Java語言編寫的。我本來可以用 C#的，但是我有意識地使用了 Java。
　　首先，我認為 Java社區(qū)正在拋棄好的軟件設計和開發(fā)實踐�，F在，對于多數 Java項目而言，要在其中找到一個好的領域對象恐怕是困難的。在我看來， Scrum和敏捷被人們看成了優(yōu)良設計的替代品，而其中的產品待定項（Product Backlog）被看成了設計本身。多數敏捷人士并不會過多地去思考這些待定項是否會影響到業(yè)務模型。我得說明， Scrum的本意絕對不是要取代設計。不管有多少項目經理想將你捆綁在持續(xù)交付這條路上，我得說 Scrum并不僅僅是要取悅于那些甘特圖（ Gantt chart）的追隨者們。然而，太多的時候，情況的確是這樣的。
　　我認為這是個很大的問題，所以我想鼓勵 Java社區(qū)重新回到領域建模中來，同時我會通過本書向大家說明，設計是可以使我們獲益的。
　　此外，在 .NET社區(qū)中已經有很好的DDD資源了，比如Jimmy Nilsson的《領域驅動設計與模式實戰(zhàn)》[Nilsson]。由于Jimmy的出色工作和其他人對Alt.NET的倡導，.NET社區(qū)中正掀起一陣優(yōu)秀設計的開發(fā)浪潮，這是Java社區(qū)需要注意的。
　　其次，我意識到 C#.NET人員在理解 Java代碼上并不存在什么困難。由于很多 DDD社區(qū)的人都在使用 C#.NET，而本書的早期校對人員也都是 C#程序員，但是我從來就沒有收到他們的抱怨。因此，我便不用顧慮這些了。
　　在我寫這本書時，業(yè)內正將目光從關系型數據庫轉向基于文檔和鍵值對的存儲方案。這是有原因的， Martin Fowler將這些存儲方案稱為“面向聚合存儲”。這種命名是恰當的，它很好地描述了在 DDD中使用 NoSQL的好處。
　　但是，就我從事咨詢的經驗來看，很多開發(fā)者還是認定了關系型數據庫和對象-關系映射。因此我想， NoSQL追隨者們應該能夠理解我在書中包含對象 -關系映射的章節(jié)。然而，我的確得承認，這可能會招致那些認為存在對象 -關系阻抗失配（Object-Relational Impedance）的人的鄙視。這無所謂，對此我表示接受，因為絕大多數人在他們的日常工作中都還得面對這種對象 -關系阻抗失配。
　　當然，在第 12章“資源庫”中，我同樣提供了基于文檔的、鍵值對的和數據網格的存儲方案。在多處地方，我都討論到了 NoSQL對聚合設計的影響。 NoSQL趨勢很有可能持續(xù)下去，那些對象 -關系型的開發(fā)者們應該注意了。在本書中你將看到，我能夠同時理解兩個陣營的觀點，并且對于雙方的觀點我都同意。這些都是技術趨勢所導致的摩擦，而這對于積極的變革是有必要的。