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
主要內容：
1. 隔離（Isolate）域
2. 實體、值對象、服務、模塊（module）
3. 域對象的生命周期
4. Representing processes as domain objects
5. Creating functions free of side effects
6. 概述（Conceptual contours）
7. 單例類
8. 擴展規范
9. 應用分析模式
10. 關聯設計模式到模型
11. 維持域的完整性
12. Formulating the domain vision statement
13. 選擇重構目標
14. 職責層
15. 創建一個可插入性的組件（component）框架
16. Bringing together large-scale structures and bounded contexts
===========================================================================================
XP假設你可以經常地、快速地通過重構來改善設計
===========================================================================================
part1, DDD的目標、定義、意義（what）
part2, Model-Driven Design, best practices, OO domain model; 架起model和實踐的橋梁；standard patterns, 術語 ->common language, all team members; 保持model和實現排成一行的各種判定；（which？?。?br>part3, 強調發現過程（how）
part4, 原理（why）
===========================================================================================
Part I: 讓領域模型發揮作用（Putting the Domain Model to Work）
模型是簡化，是抽象。
用戶應用問題域到程序中，這就是軟件中的“域”。有些域涉及現實世界，訂票業務；有些域是無形的，帳戶程序的域是錢和財務；軟件“域”很少與計算機有關，偶有例外，代碼控制系統的域是軟件開發本身。
模型是工具，用來減少負擔——與用戶活動相關的。一個合適的模型，使信息變得容易理解，集中于問題上。
域模型不是一張特別的圖，而是這張圖試圖傳達的觀點；不是僅僅在領域專家腦中的知識，而是對知識的嚴格組織和選擇性的抽象；
域模型不是只需盡可能地“現實化”一個模型，甚至在一個有形的真實世界的事物的域中，我們的模型也是一個人造的創造。（來源于生活，虛構）
///////////////////////////////////////////////////////////////////////////////////////////
DDD中模型的功用
DDD中，三種基本用法決定一個模型的選擇：
1. 模型和設計核心相互定形。
模型和實現的綁定，有利于模型相關聯，確?；谒姆治瞿軌驊玫阶罱K產品中，也有利于維護和持續開發。
2. 模型是所有項目成員的語言支柱。
因為模型和實現的綁定，開發者能夠以這種語言談論程序；因為這種語言基于模型，我們的自然語言能力能夠轉為提純這個模型本身。
3. 模型是知識精粹。
模型是項目組商定的方式，這種方式用來結構化域知識和區分感興趣的元素；
///////////////////////////////////////////////////////////////////////////////////////////
軟件的核心
軟件的核心是它有為用戶解決域關聯問題的能力。
///////////////////////////////////////////////////////////////////////////////////////////
Ch1. 消化知識（Crunching Knowledge）
2007/7/2消除術語中的沖突和歧義、技術觀點的不一致。
頭腦風暴、提純；提問、解釋。
代碼模型
//////////////////////////////////////////////////////////////////////////////////////////
有效建模的因素
1. 綁定模型和實現
通過不斷地迭代
2. 培養一門基于模型的語言
便于雙方（無理解偏差）的交流
3. 開發一個富知識模型
模型不是用來看看的，需要它做事！
4. 提純模型
5. 頭腦風暴、試驗
2007/7/3知識消化
高效的領域建模者是知識消化者。他們消化大量的信息并且探索與之關聯的點滴，嘗試組織一個個的idea、尋求使其容易理解的簡單方式。（化抽象為具體）。提純過程是對發現最與之相關的特殊知識的一個嚴格表達。
//////////////////////////////////////////////////////////////////////////////////////////
知識消化不是一個孤獨的行為。開發者和領域專家互相合作。未加工的資料可以來自領域專家的想法、已有系統的使用者、老系統開發組的經驗或者同一個領域的另外一個項目。它們來自于文檔和大量的交流。
//////////////////////////////////////////////////////////////////////////////////////////
在老的瀑布開發方式中，業務專家和分析員交談，然后分析員消化、抽象并且將結果傳達給開發者。這種方式的失敗在于缺乏反饋。分析員對模型創建全權負責，而這僅僅依靠來自業務專家的“輸入”。他們沒有機會向開發者學習或者從軟件的早期版本獲得經驗。知識流向了一個方向，但是沒有匯集。
//////////////////////////////////////////////////////////////////////////////////////////
另外一些項目使用迭代開發的方式，但是他們在建立知識時失敗了，因為他們沒有抽象。開發者到業務專家那里詢問他們想要的功能，然后就回去構建它，緊接著他們向業務專家們展示結果并詢問接下來需要做什么。如果開發者進行重構的話，或許他們能夠在持續擴展中保持軟件“干凈”，但是如果開發者對“域”沒有興趣，那么他們將只學到這個應用程序什么應該做，而不知道背后的原理。這樣的方式可以建造出可用的軟件，但是這個項目將永遠不能達到通過對老功能推論，擴展出新的強大功能的程度。
2007/7/4好的開發者將自然地開始抽象和建立一個模型，以使其可以做更多的事情。但是如果這些只是出現在技術層面，而沒有和領域專家合作，那么這些想法無疑是天真的。知識的缺乏，可以生產出完成基本任務的軟件產品，但是缺少了與領域專家思考方式的深度聯系。
//////////////////////////////////////////////////////////////////////////////////////////
項目組成員間的交互作用在所有成員一起消化這個模型時發生變化。對領域模型的不斷提純強迫開發者來學習他們正在參加的項目的重要原理，而不是機械地完成一個個功能。領域專家通常以被迫來提純他們了解的本質的方式來精煉他們自己的理解，進而得以理解軟件項目所需的概念的苛刻。（？）
//////////////////////////////////////////////////////////////////////////////////////////
所有的這些使項目組成員更加勝任知識消化。他們剔除無關的，改造模型成更加有用的形式。分析員和開發者的介入，使得它被干凈地組織和抽象，因此它對實現起到了杠桿作用。由于領域專家的介入，這個模型反射出業務的深層知識。這些抽象是真實的業務原則。
//////////////////////////////////////////////////////////////////////////////////////////
由于模型的改進，它變成一個組織不斷流過項目的信息的工具。這個模型著力于需求分析。它與編碼和設計親密接觸。在一個有效力的循環中，它深化項目組成員的視線到領域中，使他們看得更加清楚、達到對模型更進一步地提煉。這些模型從來都不是完美的；他們不斷進化，他們必須對理解領域有實踐性、有幫助，為了使應用程序可以被簡單地實現和理解，他們必須嚴格。