目標
・ふわっとした理解のDDDについてエヴァンス本を通して体系的に学習する
・各章の要約をアウトプットすることで知識を定着させる
前回の記事
第8章の内容は以下でまとめています。
【第９章】暗黙的な概念を明示的にする
ドメインモデルとコードが大きく変化するのは、議論や設計内の暗黙的な概念をモデルの中で明示的に表現した時だけである。
概念を掘り出す
暗黙的な概念を発見するためには、チームの言葉に耳を傾け、
設計の矛盾点を調べドメインに関する文献を読むといったことを行う必要がある。
言葉に耳を傾ける
ドメインエキスパートの使う言葉に耳を傾ける
・複雑なものを簡潔に述べている用語がないか？
・言葉選びを正されていないか？
・特定のフレーズに対して、困惑した表情をしていないか？
ぎこちなさを精査する
手続きによって説明しにくい複雑な処理や、新しい要求のたびに複雑になるような設計に対して
積極的にドメインエキスパートを調査に参加させモデルを蒸留させる。
矛盾について熟考する
矛盾を解決することは現実的でない場合もあるが、
異なる２つの記述が両方とも適用できるかどうかを熟考することで明らかになることもある。
文献を読む
基本的な概念や社会通念について解説している文献を読むことで
首尾一貫し深く検討されたモデルに対する見方をえられる。
何度も挑戦すること
リファクタリングをするたびに、設計はよりしなやかになり、変更が容易になる。
それほど明白でない概念をモデル化する方法
オブジェクト指向の概念で理解難しい３つのカテゴリをモデル化する。
・制約
・プロセス
・仕様
明示的な制約
/**
*バケツクラス
*/
class Bucket {
// 最大容量
private float capacity;
// 内容量
private float contents;
/**
* 注ぐ
* @param addedVolume 加えられた量
* /
public void pourIn(float addedVolume){
float volumePresent = contents + addedVolume;
contents = constrainedToCapacity(volumePresent);
}
/**
* 最大容量以下に制限する
* @param 入れられた量
* @return 入れることのできた量
* /
private float constrainedToCapacity(float volumePlacedIn){
if(volumePlacedIn > capacity) return capacity;
return volumePlacedIn;
}
}
制約によってオブジェクトが歪められる例
- 制約を評価するために、オブジェクト定義に合わないデータが必要になる
- 関連するルールが複数あるせいで、コードの重複や別の系統のオブジェクトを継承しなければならなくなる
- 実装で制約が手続型のコードの中に隠されてしまう
ドメインオブジェクトとしてのプロセス
サービスはドメインのプロセスを明示的に表現しつつ、極端に複雑なアルゴリズムを引き続きカプセル化する方法の1つだ。
仕様
・仕様
特殊な目的をもった述語的な値オブジェクトで、あるオブジェクトが何らかの基準を満たしているか判断するもの。
※述語・・・「真」or「偽」を評価する関数。「AND」や「OR」などの演算子を使用して結合することで表現される。
仕様の適用と実装
オブジェクトの目的が以下のいずれかに当てはまる場合、仕様を定義する必要がある
・オブジェクトを検証し、要求を満たしているか、何らかの目的のための準備ができているか調べる
・コレクションからオブジェクトを選択する
・要求に適合するオブジェクトを新規作成する
・検証
仕様の最も単純な用途で、仕様という概念を最も直接的にしめす利用法。
要求に応じた構築(生成)
仕様の代わりにジェネレーターのインターフェースを記述的な仕様の形で定義することで
ジェネレーターの生成物を明示的に制約できる。以下のようなメリットがある。
・ジェネレーターの実装がインターフェースから分離される。
・インターフェースが明示的にルールを示すので開発者は詳細を理解しなくてよくなる
・インターフェースが柔軟になる
・インターフェースのテストがしやすくなる
まとめ
暗黙的な概念をモデル化する方法について学んだ。。
仕様に関して、本の中では検証だけのパターンや選択のパターンなどサンプルソースを交えて
解説されており理解を深めることができた。
次は「しなやかな設計」です。
参考になったらいいねやコメントおまちしています！！