My comments
（2009-2-3）
在讀這章時，對于這章開始的2頁概述一定要反復(fù)的讀。尤其是當讀到后續(xù)小節(jié)，感覺迷失方向的時候，一定要回來再讀這部分，這部分是這章的一個高度的概括。
如果不具備會計的知識背景，花半天的時間惡補一下。建議看看《會計學(xué)原理（新編）》（徐文彬）。了解幾個關(guān)鍵的術(shù)語：賬戶,會計科目,復(fù)式記賬。
我先云山霧罩的讀了一遍，再回頭看這章的開始部分，對于Martin的闡述思路了解的清晰了，另外在惡補過基本的會計知識后，對Transaction和Summary Account理解起來老輕松了，真是磨刀不誤砍柴功J
Brief Summary
Account：賬戶
Entry：記賬分錄
Account can only be added or removed by entries. The entries provide a history of all changes of the account.
Account and Entry
Transactions
Transactions add a further degree of auditability by linking entries together. In a transaction, the items withdrawn from one account must be deposited in another. (我理解這句話的意思其實就是會計中所述的復(fù)式記賬Double entry，復(fù)式記賬一般就是指借貸記賬)
一般的Transsction就是財務(wù)上所說的“一借一貸”，而Multiegged Transsction就是財務(wù)上所說的“一借多貸”或者“一貸多借”。
導(dǎo)入以下的會計知識：
這是資產(chǎn)類帳戶的余額。如果是負債或所有者權(quán)益類帳戶，七期初余額、期末余額一般應(yīng)在貸方。
費用類帳戶和資產(chǎn)類帳戶一樣；收入和利潤帳戶和負債或所有者權(quán)益類帳戶。
“借”表示資產(chǎn)增加或負債以及所有者權(quán)益的減少；“貸”表示資產(chǎn)減少或負債以及所有者權(quán)益的增加.
“有借必有貸，借貸必相等”
Summary account：匯總賬戶
帳戶是根據(jù)會計科目開設(shè)的。會計科目既有總分類科目和明細科目，帳戶也就有總分類帳戶和明細帳戶。
‘原材料’是一個總分類帳戶，它只能概括但應(yīng)所有原材料的增減變化以其結(jié)果。在‘原材料’帳戶下面，還要按照每一種原材料分別設(shè)置明細分類帳戶。
‘應(yīng)收賬款’是一個總括反映應(yīng)收賬款結(jié)算情況的總分類帳戶，為了詳細反映應(yīng)收賬款的結(jié)算情況，還必須按每一個客戶設(shè)置應(yīng)收賬款明細分類帳戶。
Memo account：備注賬戶
備注賬戶并不需要保持平衡。
No real money leaks from or to a memo account.
Posting rules（簿記規(guī)則）
對于Posting rules，Martin要從以下的幾個方面來闡述：
1. Posting rules是什么
Posting rules allow us to build active networks of accounts that update each other and reflect business rules.
2. 如何實現(xiàn)簿記規(guī)則：Individual instance method
為什么要引入Individual instance method？這是因為簿記規(guī)則往往很復(fù)雜，不會僅僅是乘以一個系數(shù)這么簡單。例如計稅，不同的金額對應(yīng)不同的稅率。也就是說對于不同的實例（instance）會對應(yīng)不同的behavior。
3. Posting rules如何被執(zhí)行
Posting rule execution pattern describes ways in which posting rules can be triggered.
4. Posting rules在哪里定義
Posting rules for many accounts
Choosing entries
Accounting practice pattern: 這是為了給Posting rules進行分類
The source of an entry
Balance sheets and income statements(資產(chǎn)負債表和損益表)
Corresponding account
Specialized account model
Transactions
Account, entry和Transactions這三者之間的關(guān)系通過UML體現(xiàn)。這是這章的基礎(chǔ)。
entry和Transactions之間的關(guān)系就如同是先有雞還是先有蛋的問題。因為有約束條件，如果沒有創(chuàng)建Transactions就不能創(chuàng)建entry；同樣沒有entry也不能創(chuàng)建Transactions，這也是因為有約束條件。
解決方法就是Transactions負責創(chuàng)建entry，entry的創(chuàng)建操作僅能由Transactions來訪問。但是這樣或許會違背約束，No problem，我們可以定義規(guī)則就是：所有的public operations必須以所有約束條件都得到滿足為結(jié)束條件。
Transactions這個概念在實際的業(yè)務(wù)系統(tǒng)中是不存在的，它其實是人造的（artifical），是為了便于數(shù)據(jù)管理，畢竟我們現(xiàn)在用的還是關(guān)系型數(shù)據(jù)庫以及面向?qū)ο蟮脑O(shè)計方法哈。
Summary Account
注意這里Summary Account的記賬方式是和業(yè)務(wù)系統(tǒng)不同的。在實際的財務(wù)管理中，我們會在匯總賬戶和明細賬戶中分別編制會計分錄（Entry），而在業(yè)務(wù)系統(tǒng)中并不是這樣的,按照Martin的敘述：
1. The entries of a summary account are derived from the component’s entries in a recursive manner.
2. post entries only to detail accounts not to summary accounts.
Posting Rule
1. 什么是Posting Rules？(簿記規(guī)則)
Posting rule looks at a particular account and, when it sees an entry, creates another entry.
簡單的Posting Rule就是乘以一個因子，如圖Figure6.8.但是復(fù)雜的，例如計稅就要采用Figure6.9的模式。
注意這也就是為什么要引入Individual instance method的原因。（這個我也是看了2遍才明白的啊）
這句話很重要：We want the behavior to vary with each individual instance.
所以不能通過類繼承實現(xiàn)。Individual instance method就是討論如何實現(xiàn)“the behavior to vary with each individual instance”。
1. Individual instance method-如何實現(xiàn)簿記規(guī)則：
1) Singleton Class單一實例
2) Strategy Pattern
3) 使用內(nèi)部的case語句
在Posting Rule上我們要定義一系列的操作。
在Posting Rule上定義computeFor。ComputeFor包含case語句去調(diào)用上面的一系列的操作。
4) 使用帶參數(shù)的方法（Parameterized Method）
5) 解釋器Interpreter
最后Martin給出了選擇實現(xiàn)方法的原則。他的首選是：Parameterized Method。
不過我認為如果是做產(chǎn)品，解釋器Interpreter是不二的選擇。因為實際的業(yè)務(wù)系統(tǒng)的復(fù)雜程度絕不是任何人在產(chǎn)品開發(fā)過程中可以想象到的，最大的靈活性是追求的唯一目標。用開發(fā)的復(fù)雜性換取實施的靈活性。
2. Posting Rules在哪里執(zhí)行
原則：Separate the strategy of firing the posting rules from the rules themselves as much as possible to reduce the coupling between these mechanisms.
A. Eager Firing
當觸發(fā)賬戶中產(chǎn)生一個entry，posting rules就會被觸發(fā)執(zhí)行。
有2種方式：
A．在創(chuàng)建Transaction或entry的方法中posting rules被觸發(fā)。
B．使用Observer模式。Make Posting rules observer of their trigger account.這種方式比較復(fù)雜，盡量避免使用。
B. Account-based Firing基于賬戶的觸發(fā)
這是一種延時處理。對應(yīng)每個賬戶維護一個未處理交易條目列表，尤其適用于cyclic accounting system（循環(huán)記賬系統(tǒng)）。每天account處理一次。
一定要注意賬戶的處理順序。
C. Posting-rule-based Firing
和Account-based Firing相似，只是Posting rule負責管理未處理交易條目列表。這種觸發(fā)方式比較復(fù)雜，盡量避免使用哈。
D. Backward-chained Firing
以當前操作帳戶（processing account）為輸出->找到posting rule->再推導(dǎo)出對應(yīng)的account（這就是要找出哪個帳戶觸發(fā)的當前操作帳戶）->對這些帳戶進行更新
E. 如何選擇posting rule的執(zhí)行方式：
要基于一下2點來考慮：
ü Posting rule執(zhí)行的時間
ü 希望在何處捕獲錯誤
Martin對這幾種方法的評價是：
Eager Firing沒有靈活性
Account-based Firing和Posting-rule-based Firing都具有很好的靈活性，帳戶結(jié)構(gòu)簡單使用前者，若復(fù)雜，則使用后者。
4. Posting Rules在哪里定義
兩種方法：
1） knowledge and operational level，posting rules定義在account type上。
2） 使用summary account，把posting rules定義在summary account，所有子帳戶也都遵循同樣的posting rules
對于這兩種不同方法的選擇的最主要的因素就是：the degree of difference in the behavior of the candidate accounts and account types.
Choosing the entry
有三種方法：
1） Getting all entries back and then doing a selection
2） Providing a selection-specific method
3） Using a filter。Filter就是一個封裝了查詢query的對象。Pattern見Figure6.24的時序圖。