本書是Eric Evans對他自己寫的《領域驅動設計-軟體核心複雜性應對之道》的一本字典式的參考書，可用於快速查找《領域驅動設計》中的諸多概念及其簡明解釋。 其它本系列其它文章地址： [譯文]Domain Driven Design Reference（一）—— 前言 [譯文]Domain Driv ...
本書是Eric Evans對他自己寫的《領域驅動設計-軟體核心複雜性應對之道》的一本字典式的參考書，可用於快速查找《領域驅動設計》中的諸多概念及其簡明解釋。
其它本系列其它文章地址：
[譯文]Domain Driven Design Reference（一）—— 前言
[譯文]Domain Driven Design Reference（二）—— 讓模型起作用
[譯文]Domain Driven Design Reference（三）—— 模型驅動設計的構建模塊
[譯文]Domain Driven Design Reference（四）—— 柔性設計
[譯文]Domain Driven Design Reference（五）—— 為戰略設計的上下文映射
[譯文]Domain Driven Design Reference（六）—— 提煉戰略設計
你如何專註於你的核心問題，並避免陷入一大堆細枝末節？
提煉是是一種分離混合物成分的過程，以提取出一種使其更有價值和有用的形式。模型是知識的提煉。隨著每一次重構的深入，我們抽象出領域知識和優先順序的一些關鍵方面。現在，回過頭來看戰略視角，本章將探討如何區分模型的涉獵範圍並提煉整個領域模型。
核心領域
在一個大型系統中，有太多的合作組件，一切都很複雜，但都是成功的必要條件，所以領域模型的本質，真正的商業資產，可能會被掩蓋和忽略。
殘酷的現實是，並非所有設計的部分都要同樣的精煉。優先事項必須確定。為了使領域模型成為一種資產，該模型的關鍵核心必須是整潔且充分利用來創建應用程式功能。但是缺乏豐富經驗的開發者傾向於對技術基礎設施或者可清晰定義的領域問題感興趣，這些問題可以在沒有專門領域知識的情況下被理解。
因此：
歸納模型。定義一個核心域，並提供一種可以很容易區分支持模型和代碼的方法。讓最有價值和最專業的概念顯露出來。
將頂尖人才應用到核心領域，並據此招聘。在核心中花費精力尋找一個深層的模型，並開發一個柔性設計來實現系統的遠景。
通過如何支持提煉出來的核心來證明對其他任何部分的投資是合理的。
通用子域
模型的某些部分增加了複雜性，而沒有捕獲或傳播專業知識。任何無關緊要的東西都會使核心領域更難識別和理解。這個模型符合所有人都知道或者是屬於專業的一般原則，這些原則不是你的主要關註點，而是發揮輔助作用。然而，這些其他的元素對於系統的功能和模型的完整表達都是必不可少的。
因此：
識別不是你的項目動機的內聚子域。提取出這些子域的通用模型，並將它們放在單獨的模塊中。不要留下你的特點。
一旦它們被分離，將它們的後續開發優先順序置於核心領域之下，並避免你的核心去做這些任務（因為這些核心開發將從他們那裡獲得很少的領域知識）。還要考慮這些通用子域的現成解決方案或已發佈的模型。
領域願景宣言
在項目開始時，模型通常是不存在的，但是關註其發展的需求已經存在。在開發的後期階段，需要對系統的價值進行解釋，而不需要對模型進行深入研究。此外，領域模型的關鍵方面可能跨越多個限界上下文，但是根據定義，這些不同的模型不能被構造來顯示它們的共同焦點。
因此：
寫一個關於核心領域的簡短描述（大概一頁）以及它將帶來的價值，即“價值主張”。忽略那些不區分該領域模型和其它東西的方面。顯示領域模型如何服務和平衡多種利益。保持它的精簡。儘早寫下此聲明，併在獲得新見解時對其進行修改。
突出核心
領域願景宣言以廣義的術語來標識核心領域，但是它將特定的核心模型元素的識別留給了個體的解釋。除非團隊中的溝通水平非常高，否則單憑願景宣言沒有多大影響。
即使團隊成員大致知道什麼是核心領域，但不同的人不會挑出相同的元素，即使是同一個人，在不同的時間點做出的選擇也不一定是一致的。不斷過濾模型以識別關鍵部分的腦力勞動更好地將註意力集中在設計思維上，並且需要對模型有全面的認識。必須使核心域更容易看到。
對代碼進行重大的重構是識別核心領域的理想方式，但它們在短期內並不總是實用的。事實上，如果沒有團隊所缺乏的觀點，這種重大的代碼重構就很難進行。
因此（作為突出核心的一種形式）：
編寫一個非常簡短的文檔(3到7個簡單頁面)，描述核心領域和核心元素之間的主要交互。
和/或（作為突出核心的另一種形式）：
在模型的主存儲庫中標記核心領域的元素，而不是特別地試圖闡明其角色。讓開發人員輕鬆瞭解核心的內外內容。
如果濃縮文件概括了核心領域的要點，那麼它就可以作為一個實際的指標，說明模型變更的重要性。當模型或代碼變更影響到濃縮文檔時，需要與其他團隊成員協商。當更改完成時，需要立即通知所有團隊成員，並傳播新版本的文檔。除核心外的變更或未包含在濃縮文檔中的細節，可以不經協商或通知的情況下進行而集成，並且其他成員在其工作過程中也會遇到。然後開發人員擁有絕大多數敏捷過程所建議的自主權。
儘管有願景宣言和突出的核心信息和指南的存在，但是它們實際上並沒有修改模型或代碼本身。劃分通用子域將從物理上去除一些分散註意力的元素。接下來，我們將研究其它方式來結構性地更改模型和設計本身，以使核心領域更易理解和管理。。。
內聚機制
開始膨脹設計使得計算有時會達到一個複雜程式。概念性的"做什麼"被機械的"如何做"所淹沒。提供解決問題演算法的大量方法模糊了表達問題的方法。
因此：
將概念上的內聚機制分離到一個單獨的輕量級框架。特別註意形式主義或有良好文檔的演算法類別。用意圖揭示介面來公開框架的功能。現在，領域中的其他元素就可以只專註與如何表達問題（做什麼）了，而把解決方案的複雜細節（如何做）轉移給了框架。
分解通用子域會減少混亂，而內聚機制有助於封裝複雜的操作。這就留下了一個更專註的模型，減少了對用戶進行活動的方式沒有特別價值的這類干擾。但是，你不可能在沒有核心的領域模型中找到好的結果。分離的核心是採取直接的方式來結構化地標記出核心領域。。。
隔離核心
模型中的元素可能部分服務於核心領域，並且部分扮演輔助角色。核心元素可能與通用元素緊密耦合。核心的概念性內聚力可能不強或缺失。所有這些混亂和複雜關係扼殺了核心。設計師不能清楚地看到最重要的關係，導致設計薄弱。
因此：
對模型進行重構，把核心概念從支持性元素（包括定義得不清楚的那些元素）中分離出來，並增強核心的內聚性，同時減少它與其他代碼的耦合。把所有通用元素或支持性元素提取到其他對象中，並把這些對象放到其他的包中，即使這會把一些緊密耦合的元素分開。
抽象核心
即使是核心領域模型通常也有很多細節，因此溝通大局面可能是困難的。當單獨模塊中的子域之間存在很多交互時，要麼在模塊之間創建許多引用，要麼就會破壞分區的大部分價值，否則交互將不得不間接地進行，這使得模型變得模糊。
因此：
確定模型中最基本的區分概念，並將它們分為不同的類，抽象類或介面。設計這個抽象模型，以表達大部分重要組件之間的交互。將這個抽象的整體模型放在它自己的模塊中，而專門的、具體的實現類留在由子域定義的它們自己的模塊中。
作者：Zachary_Fan
出處：http://www.cnblogs.com/Zachary-Fan/p/DDDReference6.html
如果你想及時得到個人自寫文章的消息推送，歡迎掃描下麵的二維碼~。
