会社で「ドメイン駆動設計 モデリング/実装ガイド」の読書会に参加しました。
連休中に内容を見返すと、結構忘れていたので、内容をメモをすることで思い出そうと思います。
後半はこちら。
第１章 DDD概要
DDDに取り組むにあたり、言葉の定義によって混乱することが多いので、ここで以下のように定義する。
DDDとは
DDDとは、ソフトウェア開発手法の一つ。
ソフトウェアで問題解決をしようとしている対象（：ドメイン）をモデリングすることでソフトウェアの価値を高めようとする。
モデルとは
問題解決のために、物事の特定の側面を抽象化したもの。
- ドメインモデル（モデル）：ドメインの問題を解決するためのモデル
- データモデル：データの永続化方法を決めるためのモデル
モデルの例
モデルは、特定の事象を抽象化したもの。
例えば、履歴書の場合、以下の情報が読み取れる
- 名前
- 経歴
- 志望理由
- 顔写真
- 筆跡、筆圧
- 履歴書のメーカー
- 履歴書を書いた時の気持ち
これらの情報から、どのような情報をソフトウェアに取り込むかを決める過程が「抽象化」。
抽象化によってできた成果物が「モデル」。
良いモデル、良くないモデル
良いモデル
良いモデルとは、問題を解決できるモデル。
理解がしやすい、きれいに見えるなどは二の次。あくまでモデルは、問題解決のために、事象を抽象化したものである。
良くないモデル
モデルのステータスが追加できない、発生するイレギュラーケースに対応できないなど、実務での問題を解決できないモデルは、いかにテストがそろっていようと、バグが少なくても、評価されない。
良いモデルを作るには
ドメインエキスパートと会話をする
そのドメインに詳しい人（：ドメインエキスパート）と会話をし、モデルに知識を反映することが大事。
ただし、ドメインエキスパートは開発のエキスパートではないため、次の視点も必要になる。
運用して得られた発見をモデルに還元する
運用して発見した改善点は、細かく追加していく。
モデルは最初から完成せず、徐々に改善していくもの。
（そのため、コードは頻繁な変更に耐えられる作りにする必要がある。）
DDDの問題解決のアプローチ
以下のアプローチを行うことが重要。
- モデルを継続的に改善
- モデルを継続的にソフトウェアに反映
モデルの継続的な改善
ドメインについての理解を深め、モデルを継続的に改善する。
- ユビキタス言語
- 発見したモデルに関する物事を、プロダクトに関わる全ての場所において同じ言葉で表現すること
- ビジネスサイドの人とも共有する
- 会話でも、ドキュメントでも、コードでも、同じ言葉を使う
- 境界づけられたコンテキスト
- あるモデルを同じ意味で使い続ける範囲のこと
- 第３章参照のこと
モデルを継続的にソフトウェアに反映
- モデルを直接表現するコードへの反映
- 極力モデルとコードを近づける
- モデル表現を隔離するアーキテクチャ
- モデルを表現するコード意外にもUIやDBとのやりとりを表現するコードが存在する
- モデル表現と、それ以外を表現するコードが混ざるとややこしい
- モデルの表現を行うコードを「ドメイン層」として隔離する
取り組む上で重要な考え方
- 課題ドリブン
- 意思決定の際には、課題を明確にして解決できるかを考える
- ルールより課題解決ができるかを重視する
- 小さく初めて、小さく失敗する
- モデリングに1週間かけるより小さく実装する方が良い
- 小さい部分から始めて、少しずつ成功体験を積み上げる
第２章 モデリングから実装まで
ドメインモデリング
DDDでは、モデリングの方法や、アウトプット形式が迷うポイント。
今回は比較的シンプルで、小さく始めて効果を出しやすいユースケース図とドメインモデル図を利用する。
ユースケース図
ユースケース図は、「ユーザの要求に対するシステムの振る舞いを定義する図」。
ユーザを定義し、棒人間で表して、ユーザが行う動作を吹き出しで「〇〇を××する」といった形式で書き出す。
さらに、今回のモデリングにおけるスコープも、図中に明記する。
ユースケースを書き出すことで、どのようなモデルを作れば良いか判断できるようにする。
ユースケースが具体化されていないと、モデルで解決すべき問題点が明確にならず、良いモデルとそうでないモデルの区別が付かなくなってしまう。
また、モデリングにおけるスコープを明記することで、議論の発散を防ぐ。
ドメインモデル図
ドメインモデル図は、簡略化したクラス図。
- 書くこと
- オブジェクトの代表的な属性
- 「ルール」、「制約（ドメイン知識）」を示した吹き出し
- 箇条書きなど
- 状態遷移図などでもOK
- オブジェクト同士の関係
- 集約内の参照は「-◆」で表す（インスタンス参照）
- 集約外の参照は「→」で表す（ID参照）
- 多重度の定義
- 集約範囲の定義
- 具体例などもあれば
- 書かないこと
- メソッド
（ここは、書籍のP24にある図を見た方がわかりやすい。）
ドメインモデルの実装
作成したドメインモデルを、コードに落とす。
ドメインモデル貧血症
ドメインモデルを実装するためのオブジェクトでありながら、ドメイン知識をほぼ持っていないオブジェクトのこと。
書籍ではドメイン貧血症のコードをリファクタリングする。
アーキテクチャ
まず、全体のアーキテクチャを決定する。
レイヤーを定義して、各レイヤーに実装するクラスの方針を定義する。
（ここでは、オニオンアーキテクチャを採用）
詳しくは第５章参照。
ドメイン貧血症のコード
（このメモを書いている私の都合でPHPで書きます...）
public class Task
{
private id;
private taskStatus
private name;
private duDate;
private postponeCount;
// 全ての属性には、publicなsetterとgetterが存在する
}
- 問題点1：不整合なデータをいくらでも作り出せる
- 全てのsetterがpublicであるため、自由にデータを作り出せてしまう
- 仕様の把握のためには、多くのクラスやコードを辿る必要がある
- ステータスや期日変更にはどんなパターンがあるかこのクラスだけではわからない
ドメインモデル知識を表現した実装
ドメイン貧血症を防ぐためには、以下に注意する
* ドメイン知識はドメイン層で実装する
* ユースケース層で実装しない
* ユースケースには「なにをしたいか（What）」のみが記載されるようにする
* 想定外の操作が行われないようにする（例えばpublicなsetterは作成しない）
ドメイン層オブジェクト設計の基本方針
以下の2点に従う。
- ドメインモデルの知識を対応するオブジェクトに書く
- 常に正しいインスタンスしか存在させない
- 生成条件を強制する（なにもないコンストラクタは実装しない）
- 内部状態の変更を強制する（ミューテーションを起こすメソッドを正しく実装し公開する）
第３章 固有のモデリング手法
集約
集約とは、「必ず守りたい強い整合性を持ったオブジェクトのまとまり」のこと。
以下の2ルールにしたがって定義する。
- 強い整合性確保が必要なものを集約にする
- オブジェクトの属性が他のオブジェクトに強く影響する場合など
- トランザクションを必ず1つの集約にする
- 整合性を守るため、集約単位でリポジトリからデータを取り出したり、更新したりする
集約ルートとは
各集約には、ルートとなるオブジェクトを1つ決め、集約ルートと呼ぶ。
集約の決め方
- 集約の境界は、機械的な決め方は存在しない
- 整合性確保の重要性を加味して決める
- 複数集合間で整合性を確保しないわけではないので、整合性確保が必要だから必ず集合にする必要はない
- トランザクション範囲の適切さも加味する
- 大きすぎる集合だと、DBへ反映するときに負荷がかかる
境界づけられたコンテキスト
同じシステム内でも、1つの事象をすべて1モデルで表すのには無理がある。
そのため、適切な範囲でモデルがカバーする範囲を分割する。
このモデルがカバーする範囲のことを「コンテキスト」と呼ぶ。
（モデルを別にして、コンテキストが変わった時は情報を詰め替えるイメージ？？）
第４章 設計の基本原則
凝縮度
凝縮度とは、1クラスでの「責務、データ、振る舞いの関連の強さ」の尺度。
なんでもできるクラスを作るのではなく、責務に沿った内容が集約されているかどうか。
一般的に高凝縮がいいとされる。
責務を明確にするため、「このクラスは何をするクラスか」を明確にすべき。
- ❌ 低凝縮に陥る例
- クラス名自体が責務を曖昧にしている
- クラス名と関連が明確でないデータ名
- 目的語が欠如したメソッド名（「なにを」インクリメントするのか、など）
- 保持しているデータと関係ないロジック
結合度
結合度とは、複数のクラス同士が依存している度合い。
一般的に、低結合が良いとされている。
結合度が高いと、依存先クラスの修正による影響を受けやすくなる。
また、実現したい処理を、多くのクラスを組み合わせないと実現できない場合は、すでに結合度が高くなっていると考えられる。
高凝縮・低結合で得られるメリット
- コードを理解しやすくなる
- コードの修正/拡張がやりやすくなる
- バグが含まれにくくなる
コードを再利用しやすくなる
テストがしやすくなる
第５章 アーキテクチャ
DDDで提唱されているアーキテクチャの解説。
3層アーキテクチャ
概要
デメリット
以下の理由で可読性や保守性が下がる。
- ビジネスロジックが膨らむ。（低凝縮になる）
- ビジネスロジックがユースケースとドメイン知識両方を担っているため
- ビジネスロジック層とデータアクセス層が高結合になってしまう
- ドメイン知識がビジネスロジック層とデータアクセス層にあるため
レイヤードアーキテクチャ
概要
3層アーキテクチャのビジネスロジック層を2つに分けたもの。
メリット
- レイヤーごとに責務がはっきりし、可読性、保守性が上がる（高凝縮になる）。
デメリット
- ドメイン層がインフラ層に依存してしまう
- ドメイン層にリポジトリをおく場合、DBやORマッパーに依存した実装になる
モデルを継続的に改善するためには、ドメイン層はインフラ技術に依存すべきではない。
オニオンアーキテクチャ
概要
レイヤードアーキテクチャから、ドメイン層とインフラ層の依存関係を逆転させたもの。
図中の白矢印は、インターフェイスの実装を示す。
名前の通り、丸型で表すこともできる。
この場合、依存関係は「外側から内側」のみ許される。
プレゼンテーション層、インフラ層、テストは、それぞれアダプターを通して外部と通信する。
（スマホアプリ、ブラウザ、RDB、ファイル、外部サービス、結合テスト など）
- ドメイン層
- ドメイン知識の表現
- ドメイン層の独立で他の層への依存を持たせない
- 整合性が保てるメソッドのみ外部に公開する
- 実装するクラスは以下の通り
- エンティティ
- 値オブジェクト
- ドメインイベント
- リポジトリインターフェイス
- ドメインサービスファクトリー
- ユースケース層
- ドメイン層のメソッドを使ってユースケースを実現する
- 特定のクライアントに依存させない （クライアントに合わせるのはプレゼンテーション層）
- 実装するクラスは以下の通り
- ユースケースクラス
- プレゼンテーション層との入出力定義クラス
- プレゼンテーション層
- アプリケーション外部との入出力を実現
- 実装するクラスは以下の通り
- コントローラ
- アプリケーション外部との入出力を実現するクラス
- インフラ層
- 下位レイヤーのインターフェイスを実装する
- 実装するクラスは以下の通り
- リポジトリ実装クラス
メリット
- ドメイン層を特定の技術に依存させずに済む
ヘキサゴナルアーキテクチャ
概要
アプリケーションが外の世界と通信する際には、専用のポートとアダプターを作成して通信させるアーキテクチャ。
レイヤーの分け方が異なるが、基本的にはオニオンアーキテクチャの思想を踏襲したもの。
（別に六角形である意味はない。）
クリーンアーキテクチャ
概要
オニオンやヘキサゴナル、その他のアーキテクチャを受けて概念を結合しようとしたアーキテクチャ。
なお、筆者のおすすめはシンプルさと元々のDDDが目指す思想との差異から「オニオンアーキテクチャ」だそう。
境界づけられたコンテキストの実装
- 1アプリケーション1コンテキストとするのが簡単
- コンテキストごとのマイクロサービスとなる
- ただし実装コストは高くなる
- パッケージで区切ってしまう
- 逆に複雑になる時もある
- パッケージで区切る方法で始めて、後にサービスを分割する方法もアリ
後半はこちら。