ドメインオブジェクトの見つけ方

現場で役立つシステム設計を読んだので覚えておきたいことをメモしました。

ドメインオブジェクトの見つけ方

重要な関心ごとや関係性に注目する

• 最初から網羅的にドメインオブジェクトを見つけることはできない。組み立てる段階で不足に気づく。そのようにしてドメインモデルを追加していくのが、ドメインモデルで業務アプリケーションを設計していくやり方。対象となる業務データの種類は多く、闇雲に手を出すのではなく、業務の重要な関心ごとをそうでない部分に分類し、重要なところから手をつける。

重要な点を見つけたり、表面では理解しにくい重要な関係性を発見するには業務の関心ごとを分類してみる

業務の関心ごとをヒト/モノ/コトの３つに分類する方法がある。
ヒト・・・個人、企業、担当者など
モノ・・・商品、サービス、店舗、場所、権利、義務、数量、金額、率、説明、注釈、状態、日月や期間、位置など
コト・・・予約、注文、支払い、出荷、キャンセルなど

ヒト
業務活動の当事者で、意思があり、判断し、行動する主体。人という関心ごとに対応するドメインオブジェクトは人の意思/判断/行動についてのデータを持ち、そのデータを使った判断/加工/計算ロジックを持つ。
モノ
ヒトが業務を遂行するときの関心の対象。物理的なものだけでなく、権利や義務のように概念的に認識している対象もモノ。
コト
業務活動で起こる事象。業務的におきてほしいコト、起きてはいけないコトがある。業務アプリケーションの基本的な関心ごとはコトを記録し、コトの発生通知すること。
コトは基本的にヒトの意思決定や行動の結果。コトをを表現するオブジェクトがもつ一般的な属性は下記。

• 対象・・・何について発生した事象か
• 種別・・・どういう種類の事象か
• 時点・・いつ起きた事象か

コトに注目すると、全体の関係を整理しやすい

コトに注目すると下記の関係が明らかになる

• コトはヒトとモノとの関係として出現する
• コトは時間軸に沿って明確な前後関係を持つ

コトは業務ルールの宝庫

コトは単純な出来事ではなく、背後にさまざまなルールが隠されている。
そしてこのルールを理解すればするほどドメインモデルは役立つものになる。
背後に隠れたルールを理解するためにはどうすればよいか

業務ルールの記述　~手続き型とオブジェクト指向の違い~

プログラムを書く視点からは、業務ルールの実体は以下の判断ロジック

• 数値の一致や大小比較
• 日付の一致や前後比較
• 文字列の一致/不一致の判定

膨大な業務ルールを整理して定義していくと、数値/日付/文字列という基本データ型に対する判断ロジックになる。trueだった場合のアクション、falseだった場合のアクションが存在する。その最小構成単位はif文の判定と場合ごとのアクション。

手続き型の場合
　- データクラスを受け取った機能クラスでif文/swith文を使って必要な条件判断と分岐を実行する。
　- 条件の組み合わせは、基本的にif文の入れ子構造になる、これがトランザクションスクリプトと呼ばれる手続き型の業務ルールの記述方法
　- 業務ルールの追加や変更への対応の際には、業務ルールが増えるほど、分岐構造が複雑になる。

オブジェクト指向

• 判断の元になるデータとロジックごとにオブジェクトを生成する。
• それぞれのオブジェクトは自分で判断ができる。
• 判断結果によって何をすべきかの情報を保つことができる。
• さまざまな判断を担当するドメインオブジェクトを用意した上で、適切に組み合わせて判断するのがオブジェクト指向のアプローチで、if文の入れ子にはならない。
  　- 業務ルールの追加や変更への対応の際には、ルールに判断の元になるデータをもつオブジェクトの判断ロジックを追加する。
  • １つのドメインオブジェクトが持つデータは大抵の場合１つか２つで、少ないデータに関連するロジックだkなので、変更は単純で、楽で安全になるし、変更の影響範囲もそのクラスに閉じ込めやすくなる。