I'm reading
Eric Evans's book:
Domain-Driven Design: Tackling Complexity in the Heart of Software.
The page will record some notes about the book, they may be messy, confused.
2007/6/30Domain-Driven Design
主要內(nèi)容：
1. 隔離（Isolate）域
2. 實體、值對象、服務(wù)、模塊（module）
3. 域?qū)ο蟮纳芷?br>4. Representing processes as domain objects
5. Creating functions free of side effects
6. 概述（Conceptual contours）
7. 單例類
8. 擴(kuò)展規(guī)范
9. 應(yīng)用分析模式
10. 關(guān)聯(lián)設(shè)計模式到模型
11. 維持域的完整性
12. Formulating the domain vision statement
13. 選擇重構(gòu)目標(biāo)
14. 職責(zé)層
15. 創(chuàng)建一個可插入性的組件（component）框架
16. Bringing together large-scale structures and bounded contexts
===========================================================================================
XP假設(shè)你可以經(jīng)常地、快速地通過重構(gòu)來改善設(shè)計
===========================================================================================
part1, DDD的目標(biāo)、定義、意義（what）
part2, Model-Driven Design, best practices, OO domain model; 架起model和實踐的橋梁；standard patterns, 術(shù)語 ->common language, all team members; 保持model和實現(xiàn)排成一行的各種判定；（which？！）
part3, 強(qiáng)調(diào)發(fā)現(xiàn)過程（how）
part4, 原理（why）
===========================================================================================
Part I: 讓領(lǐng)域模型發(fā)揮作用（Putting the Domain Model to Work）
模型是簡化，是抽象。
用戶應(yīng)用問題域到程序中，這就是軟件中的“域”。有些域涉及現(xiàn)實世界，訂票業(yè)務(wù)；有些域是無形的，帳戶程序的域是錢和財務(wù)；軟件“域”很少與計算機(jī)有關(guān)，偶有例外，代碼控制系統(tǒng)的域是軟件開發(fā)本身。
模型是工具，用來減少負(fù)擔(dān)——與用戶活動相關(guān)的。一個合適的模型，使信息變得容易理解，集中于問題上。
域模型不是一張?zhí)貏e的圖，而是這張圖試圖傳達(dá)的觀點；不是僅僅在領(lǐng)域?qū)＜夷X中的知識，而是對知識的嚴(yán)格組織和選擇性的抽象；
域模型不是只需盡可能地“現(xiàn)實化”一個模型，甚至在一個有形的真實世界的事物的域中，我們的模型也是一個人造的創(chuàng)造。（來源于生活，虛構(gòu)）
///////////////////////////////////////////////////////////////////////////////////////////
DDD中模型的功用
DDD中，三種基本用法決定一個模型的選擇：
1. 模型和設(shè)計核心相互定形。
模型和實現(xiàn)的綁定，有利于模型相關(guān)聯(lián)，確保基于它的分析能夠應(yīng)用到最終產(chǎn)品中，也有利于維護(hù)和持續(xù)開發(fā)。
2. 模型是所有項目成員的語言支柱。
因為模型和實現(xiàn)的綁定，開發(fā)者能夠以這種語言談?wù)摮绦颍灰驗檫@種語言基于模型，我們的自然語言能力能夠轉(zhuǎn)為提純這個模型本身。
3. 模型是知識精粹。
模型是項目組商定的方式，這種方式用來結(jié)構(gòu)化域知識和區(qū)分感興趣的元素；
///////////////////////////////////////////////////////////////////////////////////////////
軟件的核心
軟件的核心是它有為用戶解決域關(guān)聯(lián)問題的能力。
///////////////////////////////////////////////////////////////////////////////////////////
Ch1. 消化知識（Crunching Knowledge）
2007/7/2消除術(shù)語中的沖突和歧義、技術(shù)觀點的不一致。
頭腦風(fēng)暴、提純；提問、解釋。
代碼模型
//////////////////////////////////////////////////////////////////////////////////////////
有效建模的因素
1. 綁定模型和實現(xiàn)
通過不斷地迭代
2. 培養(yǎng)一門基于模型的語言
便于雙方（無理解偏差）的交流
3. 開發(fā)一個富知識模型
模型不是用來看看的，需要它做事！
4. 提純模型
5. 頭腦風(fēng)暴、試驗
2007/7/3知識消化
高效的領(lǐng)域建模者是知識消化者。他們消化大量的信息并且探索與之關(guān)聯(lián)的點滴，嘗試組織一個個的idea、尋求使其容易理解的簡單方式。（化抽象為具體）。提純過程是對發(fā)現(xiàn)最與之相關(guān)的特殊知識的一個嚴(yán)格表達(dá)。
//////////////////////////////////////////////////////////////////////////////////////////
知識消化不是一個孤獨的行為。開發(fā)者和領(lǐng)域?qū)＜一ハ嗪献鳌Ｎ醇庸さ馁Y料可以來自領(lǐng)域?qū)＜业南敕ā⒁延邢到y(tǒng)的使用者、老系統(tǒng)開發(fā)組的經(jīng)驗或者同一個領(lǐng)域的另外一個項目。它們來自于文檔和大量的交流。
//////////////////////////////////////////////////////////////////////////////////////////
在老的瀑布開發(fā)方式中，業(yè)務(wù)專家和分析員交談，然后分析員消化、抽象并且將結(jié)果傳達(dá)給開發(fā)者。這種方式的失敗在于缺乏反饋。分析員對模型創(chuàng)建全權(quán)負(fù)責(zé)，而這僅僅依靠來自業(yè)務(wù)專家的“輸入”。他們沒有機(jī)會向開發(fā)者學(xué)習(xí)或者從軟件的早期版本獲得經(jīng)驗。知識流向了一個方向，但是沒有匯集。
//////////////////////////////////////////////////////////////////////////////////////////
另外一些項目使用迭代開發(fā)的方式，但是他們在建立知識時失敗了，因為他們沒有抽象。開發(fā)者到業(yè)務(wù)專家那里詢問他們想要的功能，然后就回去構(gòu)建它，緊接著他們向業(yè)務(wù)專家們展示結(jié)果并詢問接下來需要做什么。如果開發(fā)者進(jìn)行重構(gòu)的話，或許他們能夠在持續(xù)擴(kuò)展中保持軟件“干凈”，但是如果開發(fā)者對“域”沒有興趣，那么他們將只學(xué)到這個應(yīng)用程序什么應(yīng)該做，而不知道背后的原理。這樣的方式可以建造出可用的軟件，但是這個項目將永遠(yuǎn)不能達(dá)到通過對老功能推論，擴(kuò)展出新的強(qiáng)大功能的程度。
2007/7/4好的開發(fā)者將自然地開始抽象和建立一個模型，以使其可以做更多的事情。但是如果這些只是出現(xiàn)在技術(shù)層面，而沒有和領(lǐng)域?qū)＜液献鳎敲催@些想法無疑是天真的。知識的缺乏，可以生產(chǎn)出完成基本任務(wù)的軟件產(chǎn)品，但是缺少了與領(lǐng)域?qū)＜宜伎挤绞降纳疃嚷?lián)系。
//////////////////////////////////////////////////////////////////////////////////////////
項目組成員間的交互作用在所有成員一起消化這個模型時發(fā)生變化。對領(lǐng)域模型的不斷提純強(qiáng)迫開發(fā)者來學(xué)習(xí)他們正在參加的項目的重要原理，而不是機(jī)械地完成一個個功能。領(lǐng)域?qū)＜彝ǔＲ员黄葋硖峒兯麄兞私獾谋举|(zhì)的方式來精煉他們自己的理解，進(jìn)而得以理解軟件項目所需的概念的苛刻。（？）
//////////////////////////////////////////////////////////////////////////////////////////
所有的這些使項目組成員更加勝任知識消化。他們剔除無關(guān)的，改造模型成更加有用的形式。分析員和開發(fā)者的介入，使得它被干凈地組織和抽象，因此它對實現(xiàn)起到了杠桿作用。由于領(lǐng)域?qū)＜业慕槿耄@個模型反射出業(yè)務(wù)的深層知識。這些抽象是真實的業(yè)務(wù)原則。
//////////////////////////////////////////////////////////////////////////////////////////
由于模型的改進(jìn)，它變成一個組織不斷流過項目的信息的工具。這個模型著力于需求分析。它與編碼和設(shè)計親密接觸。在一個有效力的循環(huán)中，它深化項目組成員的視線到領(lǐng)域中，使他們看得更加清楚、達(dá)到對模型更進(jìn)一步地提煉。這些模型從來都不是完美的；他們不斷進(jìn)化，他們必須對理解領(lǐng)域有實踐性、有幫助，為了使應(yīng)用程序可以被簡單地實現(xiàn)和理解，他們必須嚴(yán)格。