エリックエバンスのドメイン駆動設計の「第10章しなやかな設計」まとめ

今回は、「第10章しなやかな設計」のまとめです。

初期リリース以降も、プロジェクトの進行を加速させるためには、変更に強い設計が必要不可欠です。

そのため、しなやかな設計とは『変更に強い設計』と定義されます。

DDD本で紹介されている以下6つのパターンを用いることによって、設計にしなやかさを与えることが可能になります。

No	パターン名	概要
1	意図の明白なインターフェース	名前はユビキタス言語で命名する。
2	副作用のない関数	複雑なロジックは、副作用のない関数によって、安全に実行する。
3	表明	システムの状態を変更するメソッドは、表明によって特徴づける。
4	概念の輪郭	ドメインオブジェクトは意味のある単位に分割する。
5	独立したクラス	ドメインオブジェクト間の結合は低結合にする。
6	閉じた操作	引数の型と戻り値の型が同じ場合は、閉じた操作と呼ぶ。

説明するパターンは、

に分類されます。

具体的なパターンの詳細は、一つずつ解説します。

クラス名、メソッド名に対して、手段ではなく、目的が把握できるユビキタス言語の名前をつけます。

ユビキタス言語にすることによって、チームメンバがすぐ意味を推測できるようになります。また、呼び出し側はインターフェースの内部処理を理解不要となります。

具体的な例として、以前僕が社内でやったリファクタリングのワークショップのスライドがあったので、以下を参考にしてください。

f:id:mmm-mao:20150609083816j:plain

副作用とは、システムの状態に対して行われる、あらゆる変更を意味します。

そのため、呼び出し側で、副作用があるのか/ないのかを安全に予測できることが重要となってきます。

操作は以下２つのカテゴリに分けられます。

No	カテゴリ名	概要
1	コマンド	システムに何らかの変更を与える操作
2	クエリ	システムに変更を加えずに、何らかの値を返却する操作

システムの状態を変更するメソッド（先ほどのコマンド）は、表明によって特徴づけます。

表明の表現方法としては、以下があります。

No	条件名	概要
1	事後条件	事後条件が操作の副作用なので、メソッドを呼び出すことで保証される結果を記述する
2	事前条件	事前条件とは事後条件が成り立つことを保証するために満たすべき条件
3	クラスの不変条件	あらゆる操作が終わったときのオブジェクトの状態を宣言。集約全体の整合性に関するルールを厳密に定義する

表明の具体的な表現方法としては、自動化されたユニットテストで表現することになります。

テストの内容としては、テストを準備する際に事前条件を整えて、実行後の事後条件が成り立っているかどうかを判定するだけになります。

ドメインオブジェクトは、意味のある単位をより直感的に使用したり、組み合わせたりできるような単位で分割します。

最初から理想となる分割はできず、リファクタリングした結果によるものです。

ただし、リファクタリングは技術視点ではなく、ドメイン視点で実施する必要があります。

関連が多ければ多いほど、モデルは複雑になるので、オブジェクト間の関連は低結合になるように徹底的にやります。

引数の型と戻り値の型が同じ場合は、閉じた操作と呼びます。

閉じた操作にすることによって、引数と戻り値が同じ型になるので、余計な概念を呼び込む必要がなくなります。

逆の例だと、操作の引数や戻り値に新たなクラスが登場すると、新たな依存関係ができるという現象になります。

以上が「第10章しなやかな設計」のまとめです。