例）夜間バッチへの洞察 (p301〜) †
要約 †
Posting Rules(p301） †
- p301-1
会計システムにおいて、同じ情報を、様々な視点から提供する事がしばしばある。
例えば、あるAccountは収入を追跡し、一方で別のAccountは収入に対して評価される税金を追跡する。
もし、収入に対して自動的に税金が更新される事をシステムに望まれているならば、これら２つのAccountは密接に関係しあい、そのような部分はどうやってもトリッキーになってしまう。
からみあった依存部分に対する最初のステップは新しいオブジェクトを示す事でこれらの関係を明確にする事である。
- p301-2
posting rule（転記）はinput Accountへの新しいEntryが契機となる。
この時、calculation Method に基づいて新しいEntry事が発生し、output Accountへ挿入される。
並列システムでは、給与会計に対する収入Entryに対して30％の税金を計算し、税金Entryとして挿入されるようなPosting Ruleを発生させる。
Executing Posting Rules （p302) †
- p302-1
依存性のデザインで最も掴み所のないものの一つに更新のタイミングと制御がある。
ファウラーは3つ論じている。
| 1 | 大抵は現実的ではないが一番分かりやすいのは、EntryがAccountに挿入された時は常に、Posting Ruleは即座に適用され、全ての更新が即座に実行される事 |
| 2 | あるポイントで、Accountにメッセージが送られた時にPosting Rulesが適用され、最後に挿入から未処理分に対して、Entriesの挿入が実行される。 |
| 3 | 外部エージェントの命令によってPosting Rulesが実行される。
Posting Ruleは最後の実行から全ての未処理分を探し、挿入を行う責務がある。 |
- p302-2
実行モードについては、システムの中で使い分ける事が出来るが、ある一連のルールは明確に定義されたポイントとAccount Entriesの入力に対して責任を持つ必要がある。
上述の更新のタイミングと制御をUBIQUITOUS LANGUAGEへ加える事はモデルオブジェクトを定義する事と同じくらい重要。
これは、曖昧さを排除し、明確に定義された一連の選択を決断する事へ導いてくれる。
Figure11.9 A shot at using Posting Rules in the batch †
課題：
バッチスクリプトの中で暗黙的に行われるドメインロジックがあるが、だんだん複雑になってきた。
対応：
バッチスクリプト自身をドメイン層から切り離し、単純レイヤとする事をmodel-driven-designで試みた。
結果：
オブジェクトとして意味を成していない、単なる手続きに成り下がってしまった為、ドメインモデルがどのようなものであるか理解できないものになってしまった。
そこで、アナリシスパターンの「Posting Rules」を読んで図11.9を閃いた。
（実行モード2のパターン）
Posting Serviceとは？（p303 L8） †
サービスとして会計アプリケーションの機能にアクセスするFacede(Developer2）
（バッチを単純にしようとして思いついたものだが、レガシーシステムにINTENTION-REVEALING INTERFACEを与えるものとなった。）
実行モードをどうする？(p303 L13） †
利子の発生の時点で、バッチに挿入を依頼する為に、実行モード1を考えているが、それでは一日中、支払いが発生してしまう。(Developer2）
計算メソッドの中でバッチを呼び出すような、強い結びつきは回避したいが、異なるタイミングで挿入を行うとしても、処理が煩雑になってしまい、コンセプトに反する。
Posting-Ruleありきになっているように思えるので、バッチが実行タイミングをPosting-Ruleに教え、Posting-Ruleが処理に相応しい新しいEntriesを探し出させてはどうか？(Developer1）
AccountとEntriesの関係が曖昧なのだが・・・（p304 L9） †
ファウラー本ではAccountとPosting-Ruleが直接結びついている。それは論理的なのだが、今回の要件（AccountとEntriesをデータから毎回、生成しなければいけない）に対しては、そのまま適用しても上手く機能しない。
AccountとPosting-Ruleを結びつけるために、どういった制約を適用すべきかを考えねばならないが、これは、個々の口座の中身を知っているAssetオブジェクトが妥当だろう。（Developer2）
Methodオブジェクトを正しく使ってないのでは？(p304 L17) †
Methodは、金額の内訳も示すべき（例：収入に対して20%の税金がかかっている事を知らせる）
総勘定元帳の名前に一致するPosting-Ruleならば、どの勘定口座に記帳すべきかを知っているだろう。(Developer1）
そういう事ならば、恐らくMethodオブジェクトは必要ない（Developer2）
全体のビジネスの中で、毎回に正しい総勘定元帳を特定するのは、複雑になってくるし、収入の種類は資産クラス（ビジネスが個々の資産に適用するカテゴリ）で知る事ができる。
Figure 11.10 The class diagram with PostingRules?（p305） †
これまでの議論を反映。
- AssetオブジェクトにAccountとPosting-Ruleの関連付けを調整させる。
- Posting-RuleはAssetを通してAccountを知り、挿入すべき新しいEntriesに辿り着ける。
- Posting-RuleはAccountに基づいて総勘定元帳を特定する。(Methodは廃止）
Figure11.11 Sequence diagram showing rule fireing †
- バッチがAssetに日割利子を追加
- Posting-Ruleを実行
- AssetがAccountに、ビジネスの種類と、勘定口座の名前を知っているPosting-Ruleを与え、新しいEntries（日割利子）を記帳するように指示
- Accountは与えられたビジネスの種類と挿入すべきEntryをPosting-Ruleに渡して記帳を依頼。
- Posting-Ruleはビジネスの種類から総勘定元帳を取得し、Posting Service（会計アプリへのFacade）を実行
今後の課題 (p305下から3行目） †
AssetはAccountの性質（利子や支払い）を知っており、かつバッチにとっては自然な窓口なので、Assetを通してPosting-RuleとAccountを結びつける事にしたのだが、やっぱり
- Posting-RuleはAccountsのみと結び付く
- Assetは利子の発生のみに特化させる
方が良い。これに関しては、今後のリファクタリングや、Deeper insight で解決していきたいらしい。
参考 †
会計パターンより抜粋
| Posting Rule | Determins what accounting entries to make in response to an event
(イベントに対するレスポンスとして、account entriesが何を行うべきかを決定する事） |
担当者のつぶやき †
get(assetClass)から何故、総勘定元帳名を取得する必要があるのか？’Posting-Ruleが既に知っているのでは？
p306 L8の「SINGLETON」って何をさしている？
みんなの突っ込み †
