Java EE勉強会

DDD / ExampleEarning Interest with Accounts

例）勘定口座における利子の計上(P295) †

要約 †

  • P295-3,4
    要件
  1. 貸付金と利子付資産の追跡の為のアプリケーション
  2. 利子と手数料の計算する
  3. 借主からの支払い追跡する
  4. 夜間バッチで基幹の会計システムに反映する
  5. 特定の総勘定元帳を指定する場合は、（記帳される）各金額は公開されなければならない。

    初期デザイン(Figure11.1)は出来たが、作りこむには不細工なので、「Analysis-Patterns」の6章（Inventory and Accounting. ）を読む事にした。
  • p295-5
    最も基本的な会計モデルに必要とされる事は
    金額を追跡するだけではなく、金額が増減理由を明らかに、制御できる事
  • p296-1
    Entryを挿入する事で値が追加され、負のEntryを挿入する事で値が取り除かれるが、Entriesは履歴として残っていく。
    収支バランスはEntriesの結果となる。
    収支バランスへの反映タイミングは任意。
    計算方法はAccountインタフェースによって隠蔽されている。
  • p296-2
    基本的な会計の原則は 
    Account（勘定口座）間での移動はあっても、全てのcredit（貸方）は、
debit（借方）に一致する。(Transactionno{sum(entries.amount)=0})
    上記は、double-entry book-keeping(複式簿記)のコンセプトである。
  • p296-5
    以下の三人でディスカッション。
    Developer1ファウラーの本を読んで、アイディアを得ている人
    Developer2Developer1の同僚。利子計算の設計者であり、夜間バッチのプログラマ。
    Expertドメイン・エキスパート
  • p297-Figure11.4
    履歴を追えるようにする為、クラス図に反映。
    • InterestCalculator?#interstDueAmmont?で利子の為のEntryを作成する。
    • 利子の発生を表すEntryをInterest Accountへ反映する。
    • 利子の支払いを表すEntryがバランスを取る。（FeeCalculator?#caluculateFeesForDate?がトリガ？）
  • p297-10「Transaction」について
    定義：あるAccountから別のAccountに移る事であり、反映は同時に行われる。(p297-L11)
    疑問：同じAccount間でEntryが移動する事はあるのか？(p297-L12)

    定義：1回のトランザクションが発行されるタイミングは決まっているようだ。(p297-L13)
    疑問：利子の支払いは（発生に対して）数日後に遅らせる事ができるが、タイミングをいつにする？(p297-L14)

    とりあえず、
  1. Interst Calculatorに利子発生のEntryを作成させるとバランスを制御するのに良さそう。
  2. Transactionが利子の発生と支払いを結び付けれてくれそう。
  • p298
    質問 
    「発生(accruals)」とは？(developer1 p298-L12）

    回答 
    転記するタイミング。実際に金額が動いている必要はない。(expert p298-L14）
（例：利子は毎日発生しても、反映されるのは月末）

    質問 
    何故、利子の発生を支払いと結びつける必要があるのか？
1つの発生に対して１つの支払いとは限らない。（expert p298-L1,7）

    回答： 
    古いクラス図のコピーを残しといて、変更を加えたFigure11.6ではどう？(developer1 p298-L11,18)

    「Account」で発生、支払い、バランスの全て分るようにしたかったので「Transaction」を削除
    （夜間バッチ用のスクリプトの変更も容易なモデルになった）
  • p299 L5
    新しいデザインは分析が容易で、テストもしやすくなった。
  • p299-2
    PaymentとAccrualは役割が異なり、かつ重要なドメイン概念なのでEntryの サブクラスとした(p299 L10)
    （日付に関しては利子発生、支払いで別々のテーブル上で管理）。
  • p299-3
    一方で、支払いや利子を表しているかどうかに関わらず「Entries」間では、概念や振る舞いの違いなかった。(p299 L13)
  • p299-4
    結局、日付はテーブルに格納され、Figure11-6の適用は諦めた。

参考 †

Analysis Patterns本

Accountパターン

用語説明例
Account EntryAn allocation of sum of money
合計金額の計上		仕訳
AccountCollect together related accounting entries and provide summarizing behavior
関連するAccount Entryを集約し、振る舞いの要約を提供する。		勘定口座（現金、建物、土地）
Account TransactionLink two (or more) entries together so that the total of all entries in a transaction is zero
2つ以上のEntryをトランザクションの中で合計ゼロになるようにまとめる事		貸借平均の原理
(取引における借方、貸方は常に等しい)

担当者のつぶやき †

・何故AccountでAccurual、Payment、Balanceの全てを管理させたいのか？何故、左記の要件を満たすのがFigure11.6になり得るのか分からない。（メソッドの解説が欲しい）
素直に簿記でも勉強して、用語をオブジェクトにした方が分りやすいような・・・試算表や仕訳を表すオブジェクトもないのに、Transaction（取引）を削除してBalanceをAccount（勘定口座）に管理させるのは凄く面倒だと思うんだけど・・・

・p300-2段落目「the new design was much easier･･･characterized by ASSERSIONS.」とあるが、どこら辺が、SIDE-EFFECT-FREE-FUNCTIONSでFUNCTIONS、ASSERTIONSなものになっているのか？見えてこないなぁー

みんなの突っ込み †

  • SIDE-EFFECT-FREE-FUNCTIONSに関して言うと、図11.4のcalculateInterestForDate?()は「EntryをInterest Accountに追加する」とあるので、副作用があります。それに対して、最後の図11.7のaccrualFor()はEntryを集計するだけなので副作用はなくなっているということではないでしょうか。 -- 和智? 2009-01-24 (土) 10:45:58


まとめ (議事録) †

Menu