讀后感：
Martin Fowler 20年前的書，OO和領域的思想對於今天的我們來說很基礎，但在那時應該算是萌芽。Smalltalk語言簡單，語法中省略空格可能因為那時的硬件設備昂貴，而不得不做出的選擇，但是可讀性真的很差，而書中基本是用Smalltalk進行示例。翻開這本書是為了查找財務模型，它沒有讓我失望，特別是第6章“庫存與財務”給了我思維建模的概念。這本書和UML、GOF的“設計模式”差不多是在同一時間段出現，所以書的內容看上去有點古董的感覺。不過，大師的思路有時候都是接近的。這本書還讓我聯想到，其實軟件開發領域這幾十年並沒有改變多少，對比更新迭代很快的手機來說，我們算是很幸運的了。
讀書筆記：
第1章 緒論
建模原則：概念模型是與接口（類型）而不是與實現（類）相關聯的。
建模原則：模式是起點，而不是終點。
建模原則：模型無好壞對錯之分，只有有用還是無用之分。
作者的電子郵件（郵件地址是100031.3311@compuserve.com）
第3章 觀察和測量模式
關鍵概念：數量、單位、測量、觀察、觀察概念、現象類型、關聯函數、被否決的觀察、假設
建模原則：當多個屬性與可能會在幾個類型中使用的行為相關時，就把這些屬性組合成新的基礎類型。
建模原則：操作級中的對象會經常發生變化。它們的配置由很少發生變化的知識級來約束。
建模原則：如果某個類型擁有多種相似的關聯，可以為這些關聯對象定義一個新的類型，並建立一個知識級類型來區分它們。
第4章 針對公司財務的觀察模式
關鍵概念：企業片斷、維度、測量方案、狀態類型
第6章 庫存與財務
關鍵概念：賬目、事務、條目、記入規則
建模原則：要記錄一個值的變更歷史，可以為這個值設立一個賬目。
事務明確地把取款條目和存款條目聯系起來。雙條目法反映一個基本的賬務原理。
建模原則：在使用賬目時要遵守守恆原理：需要清算的物品不能憑空生成和消失，它僅僅是從一個地方轉移到另一個地方。這使得發現和防止不守恆變得容易。
可逆性：記入規則的一個重要屬性就是它們必定是可逆的。通常我們不能刪除一個錯誤的條目，因為它要么是支付的一部分，要么出現在賬目清單上。我們清除它的作用的惟一方法就是輸入一個同樣的但是相反的條目。
建模原則：為了確認計算是如何進行的，把計算的結果表示成對象，由它來記住是由哪個計算產生的結果以及計算所使用的輸入值是什么。
圖釋：如果使用多重匯總賬目，有可能會定義一個具有重疊細目賬目的匯總賬目。集合元素不允許重復。
如果覺得真的是個問題，我們就要在組合關系上加以限制，這個限制不允許我們選擇帶有重復的子賬目。
伊利諾伊大學厄巴納-尚佩恩分校的研究人員已經在開發賬務框架方面做了大量工作。
第12章 信息系統的分層構架
我們看到會存在這樣的情況：GUI開發者理解用戶界面環境但是根本不需要了解領域模型，而外觀開發者理解領域模型但是不需要知道GUI開發。表示層/應用邏輯層的分離把需要的不同技術分割開來，從而使開發者為了做出貢獻只需要學習較少的東 我們看到會存在這樣的情況：GUI開發者理解用戶界面環境但是根本不需要了解領域模型，而外觀開發者理解領域模型但是不需要知道GUI開發。表示層/應用邏輯層的分離把需要的不同技術分割開來，從而使開發者為了做出貢獻只需要學習較少的東西。
這個分離允許從一個單獨的外觀開發出多種表示。
外觀為測試提供一個很好的平台。當外觀和表示層被合並時，基礎的計算只能夠通過GUI進行測試，這需要手工測試（或者針對回歸測試的GUI測試軟件）。當這些被分隔開時，就能夠為外觀的接口編寫一個測試程序。這樣一來，只有表示層代碼需要使用比較笨拙的工具來測試。
這個過程會發生一個例外，就是應用需要一個特殊的數據配置發生作用，並且在開始時只用一個步驟就能夠從數據庫中獲得該數據，以便改善性能。在這種情況下，一個有用的做法是領域層提供針對具體應用的裝載請求，這種請求給應用一個機會讓領域層知道它想要請求什么。在某種程度上，這損害了領域層不應當知道什么應用使用它的原則，但是在一些環境中性能的改善是強制的。
一個解決方法是增加另一個層次——數據庫接口層，它負責從數據庫中為領域層裝載數據和當領域改變時更新數據庫。這個層也負責處理輸入以及其它遺留交互。
