Domain Driven Designのライト版
dddのこと調べていたらあったので読んでみた。
なるほどなと思ったことをメモ
下記からpdfダウンロードできます
https://www.infoq.com/jp/minibooks/domain-driven-design-quickly
- ドメインとはソフトウェアが価値を生み出す業務領域
ワークフローの集まり？これを開発者が理解する必要がある。
詳細なワークフローを知る人物からドメインを抽出する必要がある？
コードの設計上のミスは簡単に修正できるが、
ソフトウェアの設計上の失敗には多くのコストがかかる
-
ドメインモデルの設計≒ソフトウェア設計
そのあとに細部の要素を決める、コードの設計がある -
ドメインの専門家は、高度な専門的知識を持っているがその知識を
独特の方法で組み立てて使う。
この方法にシステムを合わせると、人にシステムを合わせることになりプロダクトが失敗する？
そうではなくて、専門家との議論の中からいくつかのカギとなる概念を掘り出し
システムと人がうまく適応できるようなモデリングを行っていくのがよいらしい
→ドメインモデルを共に作成する。
ソフトウェアとドメインを一体にさせるため。ここに時間をかけてかまわない。 -
ドメインモデルを作る際には、共通認識として持てる言葉を設定する。
これは、開発者のみがわかる言語でも、ドメインの専門家のみがわかる言語ではダメ。
モデルからコードへの変換
- 分析モデル
業務ドメインを分析した結果。
ソフトウェアとして実装することを考慮していない。
あくまでドメインをよく理解しようとするためのもの
アナリストがこれを開発者に丸投げしてしまうとコード設計者(開発者)独自の
意図や、アナリストが持っているドメインの知識が失われてしまう。
開発者は図やモデルから全てをくみ取ることはできない。
→間違った実装につながる
コードの設計の前にアナリストと会議に参加してドメインとモデルについての
見通しを完璧にしておく
エンティティ
システムの中で一意性が保たれるべきオブジェクト。例えばidで区別される
バリューオブジェクト
ドメインの側面を表現するためのオブジェクトで一意性を保つ必要がないもの
ドメインの要素を属性にするときに、その属性を含むオブジェクトを
識別するよりもどんな属性を含むかに関心がある場合
ex.)
線を描画する際に用意するPointクラス。
このクラスは、自らの座標だけに関心を持っていればいい。
なるべく変数の上位概念は取り出しておく
例えば、street, city, stateはAddressクラスにしておくなど
サービス
内部に情報を保持せず、単純に機能だけを提供する
サービス≠サービスとして振る舞うオブジェクト
→操作を実行するオブジェクトや操作の対象となるオブジェクトと関係する
結局、オブジェクトに適切と思われないような振る舞いはサービスとして
定義しましょうってこと
適切じゃないっていうのは、
ある２つのオブジェクト利用して計算をするときとか
色々なオブジェクトを利用してファイル出力行うとか
やはり、複数オブジェクトをつなげる役割のときに使われるものな感じ
ドメインオブジェクトのような業務ロジックなどがあたる
サービスの特徴
-
サービスとして作成される操作はドメインの概念をあらわしているが
エンティティやバリューオブジェクトに含めると違和感がある。 -
サービスとして作成される操作はドメイン内の他のオブジェクトから参照される。
-
サービスとして作成される操作は状態をもたない。
モジュール
関係の強いクラス同士をグループ化してモジュールに含めて
モジュールの凝集度は高いほうがいい
ドメインが肥大してきた時の、サービスが集まる上位概念？
凝集度の種類
-
通信滴凝集
モジュールの各部分が同じデータを操作する -
機能的凝集
モジュール全体にまたがって１つのうまく定義されたタスクを実行
後者が最良の凝集らしい。