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/30
Domain-Driven Design

主要內(nèi)容：
1. 隔離（Isolate）域
2. 實(shí)體、值對(duì)象、服務(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è)計(jì)模式到模型
11. 維持域的完整性
12. Formulating the domain vision statement
13. 選擇重構(gòu)目標(biāo)
14. 職責(zé)層
15. 創(chuàng)建一個(gè)可插入性的組件（component）框架
16. Bringing together large-scale structures and bounded contexts
===========================================================================================
XP假設(shè)你可以經(jīng)常地、快速地通過重構(gòu)來改善設(shè)計(jì)
===========================================================================================
part1, DDD的目標(biāo)、定義、意義（what）
part2, Model-Driven Design, best practices, OO domain model; 架起model和實(shí)踐的橋梁；standard patterns, 術(shù)語 ->common language, all team members; 保持model和實(shí)現(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）
模型是簡(jiǎn)化，是抽象。
用戶應(yīng)用問題域到程序中，這就是軟件中的“域”。有些域涉及現(xiàn)實(shí)世界，訂票業(yè)務(wù)；有些域是無形的，帳戶程序的域是錢和財(cái)務(wù)；軟件“域”很少與計(jì)算機(jī)有關(guān)，偶有例外，代碼控制系統(tǒng)的域是軟件開發(fā)本身。
模型是工具，用來減少負(fù)擔(dān)——與用戶活動(dòng)相關(guān)的。一個(gè)合適的模型，使信息變得容易理解，集中于問題上。
域模型不是一張?zhí)貏e的圖，而是這張圖試圖傳達(dá)的觀點(diǎn)；不是僅僅在領(lǐng)域?qū)＜夷X中的知識(shí)，而是對(duì)知識(shí)的嚴(yán)格組織和選擇性的抽象；
域模型不是只需盡可能地“現(xiàn)實(shí)化”一個(gè)模型，甚至在一個(gè)有形的真實(shí)世界的事物的域中，我們的模型也是一個(gè)人造的創(chuàng)造。（來源于生活，虛構(gòu)）
///////////////////////////////////////////////////////////////////////////////////////////
DDD中模型的功用
DDD中，三種基本用法決定一個(gè)模型的選擇：
1. 模型和設(shè)計(jì)核心相互定形。
模型和實(shí)現(xiàn)的綁定，有利于模型相關(guān)聯(lián)，確保基于它的分析能夠應(yīng)用到最終產(chǎn)品中，也有利于維護(hù)和持續(xù)開發(fā)。
2. 模型是所有項(xiàng)目成員的語言支柱。
因?yàn)槟Ｐ秃蛯?shí)現(xiàn)的綁定，開發(fā)者能夠以這種語言談?wù)摮绦颍灰驗(yàn)檫@種語言基于模型，我們的自然語言能力能夠轉(zhuǎn)為提純這個(gè)模型本身。
3. 模型是知識(shí)精粹。
模型是項(xiàng)目組商定的方式，這種方式用來結(jié)構(gòu)化域知識(shí)和區(qū)分感興趣的元素；
///////////////////////////////////////////////////////////////////////////////////////////
軟件的核心
軟件的核心是它有為用戶解決域關(guān)聯(lián)問題的能力。
///////////////////////////////////////////////////////////////////////////////////////////
Ch1. 消化知識(shí)（Crunching Knowledge）

2007/7/2
消除術(shù)語中的沖突和歧義、技術(shù)觀點(diǎn)的不一致。
頭腦風(fēng)暴、提純；提問、解釋。
代碼模型
//////////////////////////////////////////////////////////////////////////////////////////
有效建模的因素
1. 綁定模型和實(shí)現(xiàn)
通過不斷地迭代
2. 培養(yǎng)一門基于模型的語言
便于雙方（無理解偏差）的交流
3. 開發(fā)一個(gè)富知識(shí)模型
模型不是用來看看的，需要它做事！
4. 提純模型
5. 頭腦風(fēng)暴、試驗(yàn)

2007/7/3
知識(shí)消化
高效的領(lǐng)域建模者是知識(shí)消化者。他們消化大量的信息并且探索與之關(guān)聯(lián)的點(diǎn)滴，嘗試組織一個(gè)個(gè)的idea、尋求使其容易理解的簡(jiǎn)單方式。（化抽象為具體）。提純過程是對(duì)發(fā)現(xiàn)最與之相關(guān)的特殊知識(shí)的一個(gè)嚴(yán)格表達(dá)。
//////////////////////////////////////////////////////////////////////////////////////////
知識(shí)消化不是一個(gè)孤獨(dú)的行為。開發(fā)者和領(lǐng)域?qū)＜一ハ嗪献鳌Ｎ醇庸さ馁Y料可以來自領(lǐng)域?qū)＜业南敕ā⒁延邢到y(tǒng)的使用者、老系統(tǒng)開發(fā)組的經(jīng)驗(yàn)或者同一個(gè)領(lǐng)域的另外一個(gè)項(xiàng)目。它們來自于文檔和大量的交流。
//////////////////////////////////////////////////////////////////////////////////////////
在老的瀑布開發(fā)方式中，業(yè)務(wù)專家和分析員交談，然后分析員消化、抽象并且將結(jié)果傳達(dá)給開發(fā)者。這種方式的失敗在于缺乏反饋。分析員對(duì)模型創(chuàng)建全權(quán)負(fù)責(zé)，而這僅僅依靠來自業(yè)務(wù)專家的“輸入”。他們沒有機(jī)會(huì)向開發(fā)者學(xué)習(xí)或者從軟件的早期版本獲得經(jīng)驗(yàn)。知識(shí)流向了一個(gè)方向，但是沒有匯集。
//////////////////////////////////////////////////////////////////////////////////////////
另外一些項(xiàng)目使用迭代開發(fā)的方式，但是他們?cè)诮⒅R(shí)時(shí)失敗了，因?yàn)樗麄儧]有抽象。開發(fā)者到業(yè)務(wù)專家那里詢問他們想要的功能，然后就回去構(gòu)建它，緊接著他們向業(yè)務(wù)專家們展示結(jié)果并詢問接下來需要做什么。如果開發(fā)者進(jìn)行重構(gòu)的話，或許他們能夠在持續(xù)擴(kuò)展中保持軟件“干凈”，但是如果開發(fā)者對(duì)“域”沒有興趣，那么他們將只學(xué)到這個(gè)應(yīng)用程序什么應(yīng)該做，而不知道背后的原理。這樣的方式可以建造出可用的軟件，但是這個(gè)項(xiàng)目將永遠(yuǎn)不能達(dá)到通過對(duì)老功能推論，擴(kuò)展出新的強(qiáng)大功能的程度。

2007/7/4
好的開發(fā)者將自然地開始抽象和建立一個(gè)模型，以使其可以做更多的事情。但是如果這些只是出現(xiàn)在技術(shù)層面，而沒有和領(lǐng)域?qū)＜液献鳎敲催@些想法無疑是天真的。知識(shí)的缺乏，可以生產(chǎn)出完成基本任務(wù)的軟件產(chǎn)品，但是缺少了與領(lǐng)域?qū)＜宜伎挤绞降纳疃嚷?lián)系。
//////////////////////////////////////////////////////////////////////////////////////////
項(xiàng)目組成員間的交互作用在所有成員一起消化這個(gè)模型時(shí)發(fā)生變化。對(duì)領(lǐng)域模型的不斷提純強(qiáng)迫開發(fā)者來學(xué)習(xí)他們正在參加的項(xiàng)目的重要原理，而不是機(jī)械地完成一個(gè)個(gè)功能。領(lǐng)域?qū)＜彝ǔＲ员黄葋硖峒兯麄兞私獾谋举|(zhì)的方式來精煉他們自己的理解，進(jìn)而得以理解軟件項(xiàng)目所需的概念的苛刻。（？）
//////////////////////////////////////////////////////////////////////////////////////////
所有的這些使項(xiàng)目組成員更加勝任知識(shí)消化。他們剔除無關(guān)的，改造模型成更加有用的形式。分析員和開發(fā)者的介入，使得它被干凈地組織和抽象，因此它對(duì)實(shí)現(xiàn)起到了杠桿作用。由于領(lǐng)域?qū)＜业慕槿耄@個(gè)模型反射出業(yè)務(wù)的深層知識(shí)。這些抽象是真實(shí)的業(yè)務(wù)原則。
//////////////////////////////////////////////////////////////////////////////////////////
由于模型的改進(jìn)，它變成一個(gè)組織不斷流過項(xiàng)目的信息的工具。這個(gè)模型著力于需求分析。它與編碼和設(shè)計(jì)親密接觸。在一個(gè)有效力的循環(huán)中，它深化項(xiàng)目組成員的視線到領(lǐng)域中，使他們看得更加清楚、達(dá)到對(duì)模型更進(jìn)一步地提煉。這些模型從來都不是完美的；他們不斷進(jìn)化，他們必須對(duì)理解領(lǐng)域有實(shí)踐性、有幫助，為了使應(yīng)用程序可以被簡(jiǎn)單地實(shí)現(xiàn)和理解，他們必須嚴(yán)格。