概要 †
キーワード †
ドメイン †
問題領域、対象領域
特徴 †
ドメインロジックに焦点を合わせる †
- ドメインの状況を表している値の種類をまず見つける
- それに対してどんな計算ロジック、判定ロジックがあるかということを見つけ出す
- その判定結果や計算結果をどう表現するかを決める
- 以下はドメインロジック以外の関心事 ＝ ドメインロジックに従属すべき関心事
- ドメインロジックに焦点を合わせる理由
- ソフトウェアの複雑さの原因は、ドメインロジック（計算ロジックと判定ロジック）にある
- ドメインロジックと入出力が混在していると、ドメインロジックの全体像や構造が見えてこない
- 入出力の関心事を分離して、ドメインロジックだけを対象にすると、ドメインロジックの輪郭や構造がはっきりしてくる
- ドメインロジックの輪郭や構造が見えてくると、計算ロジックと判定ロジックの発見が進み、ロジックの整理がやりやすくなる
- 計算ロジックと判定ロジックが整理できると、入出力の記述もシンプルになる
- ソフトウェア全体の見通しが良くなり、変更が楽で安全になる
オブジェクト指向でモデル化する †
インクリメンタルに設計する †
ドメインモデルを表現する要素 †
エンティティ (参照オブジェクト) †
ドメインモデル内のオブジェクトであり、その属性によってではなく、連続性と識別性によって定義される。
値オブジェクト †
事物の特性を記述するオブジェクトである。特に識別する情報はなく、通例、読み出し専用のオブジェクトであり、Flyweight パターンを用いて共有できる。
サービス †
操作がオブジェクトに属さない場合に、問題の自然な解決策として、操作をサービスとして実現することができる。サービスの概念は、GRASPにおいて"純粋人工物"と呼ばれるものである。
リポジトリ †
ドメインオブジェクトを取得するメソッドは、記憶域の実装を簡単に切り替えられるようにするため、専門のリポジトリオブジェクトに処理を委譲するべきである。
ファクトリー †
ドメインオブジェクトを生成するメソッドは、実装を簡単に切り替えられるようにするため、専門のファクトリーオブジェクトに処理を委譲するべきである。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
