概要 †
キーワード †
ドメイン †
問題領域、対象領域
特徴 †
ドメインロジックに焦点を合わせる †
- ドメインの状況を表している値の種類をまず見つける
- それに対してどんな計算ロジック、判定ロジックがあるかということを見つけ出す
- その判定結果や計算結果をどう表現するかを決める
- 以下はドメインロジック以外の関心事 ＝ ドメインロジックに従属すべき関心事
- ドメインロジックに焦点を合わせる理由
- ソフトウェアの複雑さの原因は、ドメインロジック（計算ロジックと判定ロジック）にある
- ドメインロジックと入出力が混在していると、ドメインロジックの全体像や構造が見えてこない
- 入出力の関心事を分離して、ドメインロジックだけを対象にすると、ドメインロジックの輪郭や構造がはっきりしてくる
- ドメインロジックの輪郭や構造が見えてくると、計算ロジックと判定ロジックの発見が進み、ロジックの整理がやりやすくなる
- 計算ロジックと判定ロジックが整理できると、入出力の記述もシンプルになる
- ソフトウェア全体の見通しが良くなり、変更が楽で安全になる
オブジェクト指向でモジュール化する †
インクリメンタルに設計する †
- 対象領域の知識を少しずつ広げ、掘り下げる
- 最初に書いたコードを見直しながら改善する
- 時間とともに具体的で詳細になっていく要求を、時間とともにコードに反映する
- 時間とともに変化する要求を、時間とともにコードに反映する
ドメインモデルを表現する要素 †
エンティティ (参照オブジェクト) †
ドメインモデル内のオブジェクトであり、その属性によってではなく、連続性と識別性によって定義される。
値オブジェクト †
事物の特性を記述するオブジェクトである。特に識別する情報はなく、通例、読み出し専用のオブジェクトであり、Flyweight パターンを用いて共有できる。
サービス †
操作がオブジェクトに属さない場合に、問題の自然な解決策として、操作をサービスとして実現することができる。サービスの概念は、GRASPにおいて"純粋人工物"と呼ばれるものである。
リポジトリ †
ドメインオブジェクトを取得するメソッドは、記憶域の実装を簡単に切り替えられるようにするため、専門のリポジトリオブジェクトに処理を委譲するべきである。
ファクトリー †
ドメインオブジェクトを生成するメソッドは、実装を簡単に切り替えられるようにするため、専門のファクトリーオブジェクトに処理を委譲するべきである。
DTO (Data Transfer Object) †
DPO (Data Payload Object) †
他の設計方法との比較 †
モデリング †
戦略的モデリング †
戦術的モデリング †
ユースケース図 †
- モデリングする際は、必ずユースケース図から始める
- モデリングというのは何か問題を解決するために現実世界の一部を抽象化することなので、どのように使用するのかを定めなければモデリングの目的がわからなくなってしまうから
- ユースケース図を書くことで、モデリング参加者の間でモデルの用途の認識が揃う
- モデリングするスコープを限定する効果もある
- 大概において、システム化したいものは多くあるので、スコープを切らないと際限なく広がってしまい話が発散してしまいがち
ドメインモデル図 †
アーキテクチャ †
オニオンアーキテクチャ †
言語別 †
Go †
PHP †
オーガニグラフ †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
