領域驅動設計-讀書筆記-第十五章-精煉
什麼是精煉？
上面這4個方程式，再加上其中的術語定義，以及它們所依賴的數學體系，表達了19世紀經典電磁學的所有內涵。算法
如何才能專一於核心問題而不被大量的次要問題淹沒呢？LAYEREDAR CHITECTURE能夠把領域概念從技術邏輯中（技術邏輯確保了計算機系統可以運轉）分離出來，但在大型系統中，即便領域被分離出來，它的複雜性也可能仍然難以管理。精煉是把一堆混雜在一塊兒的組件分開的過程，以便經過某種形式從中提取出最重要的內容，而這種形式將使它更有價值，也更有用。模型就是知識的精煉。編程
領域模型的戰略精煉包括如下部分：
(1) 幫助全部團隊成員掌握系統的整體設計以及各部分如何協調工做；
(2) 找到一個具備適度規模的核心模型並把它添加到通用語言中，從而促進溝通；
(3) 指導重構；
(4) 專一於模型中最有價值的那部分；
(5) 指導外包、現成組件的使用以及任務委派。框架
此圖說明，經過戰略精煉提煉核心模型的幾種方式，下面分別詳細看下。dom
模式：CORE DOMAIN
CORE DOMAIN是系統中最有價值的部分。須要對模型進行提煉。找到CORE DOMAIN並提供一種易於區分的方法把它與那些起輔助做用的模型和代碼分開。最有價值和最專業的概念要輪廓分明。儘可能壓縮CORE DOMAIN。讓最有才能的人來開發CORE DOMAIN，並據此要求進行相應的招聘。在CORE DOMAIN中努力開發可以確保實現系統藍圖的深層模型和柔性設計。學習
選擇核心設計
對CORE DOMAIN的選擇取決於看問題的角度。對象
一個應用程序的CORE DOMAIN在另外一個應用程序中可能只是通用的支持組件。儘管如此，仍然能夠在一個項目中（並且一般在一個公司中）定義一個一致的CORE。像其餘設計部分同樣，人們對CORE DOMAIN的認識也會隨着迭代而發展。開始時，一些特定關係可能顯得不重要。而最初被認爲是核心的對象可能逐漸被證實只是起支持做用。blog
工做分配接口
在項目團隊中，技術能力最強的人員每每缺少豐富的領域知識。這限制了他們的做用，而且更傾向於分派他們來開發一些支持組件，從而造成了一個惡性循環——知識的缺少使他們遠離了那些可以學到領域知識的工做。資源
如何良性的進行分配呢？
創建一支由開發人員和一位或多位領域專家組成的聯合團隊，其中開發人員必須能力很強、可以長期穩定地工做而且對學習領域知識很是感興趣，而領域專家則要掌握深厚的業務知識。
精煉的逐步提高
介紹各類精煉技術。以下：
1）DOMAIN VISION STATEMENT（領域願景說明）：需不多的投入，它傳達了基本概念以及它們的價值。
2）HIGHLIGHTED CORE（突出核心）: 能夠增進溝通，並指導決策制定，這也只需對設計進行不多的改動甚至無需改動。
3）GENERIC SUBDOMAIN（通用子域）：經過重構和從新打包顯式地分離出通用子域。
4）COHESIVE MECHANISM（封裝原理）：保持設計的通用性、易懂性和柔性。
5）SEGREGATED CORE（分離核心）：從新打包出一個SEGREGATED CORE（分離的核心），可使這個CORE清晰可見
（即便在代碼中也是如此），而且促進未來在CORE模型上的工做。
6) ABSTRACT CORE（抽象內核）: 用純粹的形式表示了最基本的概念和關係（所以，須要對模型進行全面的從新組織和重構）。
模式：GENERIC SUBDOMAIN（通用子域）
模型中最普通的那些部分分離出去，它們就是GENERIC SUBDOMAIN（通用子領域）。GENERIC SUBDOMAIN與CORE DOMAIN造成鮮明的對比，使咱們能夠更清楚地理解它們各自的含義。
識別出那些與項目意圖無關的內聚子領域。把這些子領域的通用模型提取出來，並放到單獨的MODULE中。任何專有的東西都不該放在這些模塊中。把它們分離出來之後，在繼續開發的過程當中，它們的優先級應低於CORE DOMAIN的優先級，而且不要分派核心開發人員來完成這些任務（由於他們不多可以從這些任務中得到領域知識）。
當開發這樣的軟件包，有如下幾種選擇：
1）有時能夠購買一個已實現好的解決方案，或使用開源代碼。
2）參考別人公開發布的設計或模型。當有一個被普遍使用的模型時，如《分析模式》[Fowler 1996]一書中所列舉的那些模型（參見第11章），這種方法最爲有效。
3）把實現外包出去。
4）內部團隊成員實現。
其實，通用子域的實現，並不是是從這些選擇裏面選擇一個，而是根據實際狀況，去選擇多個，例如如今須要依賴短信服務，其做爲一個通用子域，就須要購買解決方案外加內部開發人員進行對接開發。
模式：DOMAIN VISION STATEMENT（領域願景說明）
不少項目團隊都會編寫「願景說明」以便管理。最好的願景說明會展現出應用程序爲組織帶來的具體價值。
DOMAIN VISION STATEMENT就是模仿這類文檔建立的，但它關注的重點是領域模型的本質，以及如何爲企業帶來價值。在項目開發的全部階段，管理層和技術人員均可以直接用領域願景說明來指導資源分配、建模選擇和團隊成員的培訓。若是領域模型爲多個羣體提供服務，那麼此文檔還可以顯示出他們的利益是如何均衡的。
DOMAIN VISION STATEMENT能夠用做一個指南，它幫助開發團隊在精煉模型和代碼的過程當中保持統一的方向。團隊中的非技術成員、管理層甚至是客戶也均可以共享領域願景說明（固然，包含專有信息的狀況除外）。
目前，我司也有每一個應用的願景，可是尚未細化到具體的領域模型這塊，看來還得繼續完善啊，願景確實能讓你們在思想上達成高度一致，而且能夠保持這對願景的憧憬和爲了實現最終願景的奮鬥意識。
模式：HIGHLIGHTED CORE（突出核心）
突出核心做爲一個方式，能夠經過簡短的文檔描述以及在文檔上標記，用來代表出模型裏面最核心的部分，讓人一目瞭然。
編寫一個很是簡短的文檔（3～7頁，每頁內容沒必要太多），用於描述CORE DOMAIN以及CORE元素之間的主要交互過程。
把模型的主要存儲庫中的CORE DOMAIN標記出來。使開發人員很容易就知道什麼在覈心內，什麼在覈心外。
模式：COHESIVE MECHANISM（內聚機制）
概念上的COHESIVE MECHANISM（內聚機制），能夠分離一些複雜的算法或者公式，到一個單獨的輕量級框架中。要特別注意公式或那些有完備文檔的算法。用一個INTENTION-REVEALING INTERFACE來暴露這個框架的功能。如今，領域中的其餘元素就能夠只專一於如何表達問題（作什麼）了，而把解決方案的複雜細節（如何作）轉移給了框架。
而後，這些被分離出來的機制承擔起支持的任務，從而留下一個更小的、表達得更清楚的CORE DOMAIN，這個核心以更加聲明式的方式經過接口來使用這些機制。
GENERIC SUBDOMAIN（通用子域）與 COHESIVE MECHANISM（內聚機制）的區別？
GENERIC SUBDOMAIN與COHESIVE MECHANISM的動機是相同的——都是爲COREDOMAIN減負。
區別在於兩者所承擔的職責的性質不一樣。GENERIC SUBDOMAIN是以描述性的模型做爲基礎的，它用這個模型表示出團隊會如何看待領域的某個方面。在這一點上它與CORE DOMAIN沒什麼區別，只是重要性和專門程度較低而已。COHESIVE MECHANISM並不表示領域，它的目的是解決描述性模型所提出來的一些複雜的計算問題。
模式：SEGREGATED CORE （分離核心）
經過重構獲得SEGREGATED CORE的通常步驟以下所示：
- 識別出一個CORE子領域（多是從精煉文檔中獲得的）。
- 把相關的類移到新的MODULE中，並根據與這些類有關的概念爲模塊命名。
- 對代碼進行重構，把那些不直接表示概念的數據和功能分離出來。把分離出來的元素放到其餘包的類（能夠是新的類）中。儘可能把它們與概念上相關的任務放在一塊兒，但不要爲了追求完美而浪費太長時間。把注意力放在提煉CORE子領域上，而且使CORE子領域對其餘包的引用變得更明顯且易於理解。
- 對新的SEGREGATED CORE MODULE進行重構，使其中的關係和交互變得更簡單、表達得更清楚，而且最大限度地減小並澄清它與其餘MODULE的關係（這將是一個持續進行的重構目標）。
- 對另外一個CORE子領域重複這個過程，直到完成SEGREGATED CORE的工做。
就像不少戰略設計決策所要求的同樣，建立SEGREGATED CORE須要整個團隊一致行動。這一行動須要團隊的一致決策，並且團隊必須足夠自律和協調才能執行這樣的決策。困難之處在於既要約束每一個人使其都使用相同的CORE定義，又不能一成不變地去執行這個決策。因爲CORE DOMAIN也是不斷演變的（像任何其餘設計方面同樣），在處理SEGREGATED CORE的過程當中咱們會不斷積累經驗，這將使咱們對什麼是核心什麼是支持元素這些問題產生新的理解。咱們應該把這些理解反饋到設計中，從而獲得更完善的CORE DOMAIN和SEGREGATED CORE MODULE的定義。
這意味着新的理解必須持續不斷地在整個團隊中共享，但我的（或編程對）不能單方面根據這些理解擅自採起行動。不管團隊採用了什麼樣的決策過程，團隊一致經過也好，由領導者下命令決定也好，決策過程都必須具備足夠的敏捷性，能夠反覆糾正。團隊必須進行有效的溝通，以便使每一個人都共享同一個CORE視圖。
模式：ABSTRACT CORE（抽象模式）
一般，即使是CORE DOMAIN模型也會包含太多的細節，以致於它很難表達出總體視圖。
咱們處理大模型的方法一般是把它分解爲足夠小的子領域，以便可以掌握它們並把它們放到一些獨立的MODULE中。這種簡化式的打包風格一般是行之有效的，可以使一個複雜的模型變得易於管理。但有時建立獨立的MODULE反而會使子領域之間的交互變得晦澀難懂，甚至變得更復雜。
咱們不妨考慮採用橫向切割而不是縱向切割的方式。多態性（polymorphism）容許咱們忽略抽象類型實例的不少細節變化。若是MODULE之間的大部分交互均可以在多態接口這個層次上表達出來，那麼就能夠把這些類型重構到一個特定的CORE MODULE中。
把模型中最基本的概念識別出來，並分離到不一樣的類、抽象類或接口中。設計這個抽象模型，使之可以表達出重要組件之間的大部分交互。把這個完整的抽象模型放到它本身的MODULE中，而專用的、詳細的實現類則留在由子領域定義的MODULE中。
深層次模型精煉
精煉並不只限於從總體上把領域中的一些部分從CORE中分離出來。它也意味着，對子領域（特別是CORE DOMAIN）進行精煉，經過持續重構獲得更深層的理解，從而向深層模型和柔性設計推動。精煉的目標是把模型設計得更明顯，使咱們能夠用
模型簡單地把領域表示出來。深層模型把領域中最本質的方面精煉成一些簡單的元素，使咱們能夠把這些元素組合起來解決應用程序中的重要問題。
當你遇到一個雜亂無章的大型系統時，應該從哪裏入手呢？
應首先集中精力把CORE DOMAIN更好地提取出來，完善對CORE的分離，而且把支持性的子領域提煉成通用子領域。
總結
大道至簡，複雜系統中最核心最有價值的部分即Core Domian，重點描述了提煉Core Domian的幾項措施，分別是：1）HIGHLIGHTED CORE（突出核心），經過標註或者短篇文檔說明，來識別出複雜系統內的Core Domian。2）DOMAIN VISION STATEMENT，創建一個核心領域模型的願景，描述其核心模型的業務價值，使其團隊內全部人在高維上達成統一。3）在Core Domain的基礎上提煉出通用子域，減小core domian的職責。4）對於Core Domain中的一些複雜算法或者公式，能夠經過內聚機制提煉到單獨的框架。5）經過在重構的過程當中不斷分離出Core Domain，由於Core Domain是不斷變化的。6）能夠採用抽象模式在代碼層面對Core Domain進行設計。