「ドメイン駆動設計 モデリング／実践ガイド」を参考にドメイン駆動設計についてまとめます。
ドメイン駆動設計とは
DDDはドメインモデリングによってソフトウェアの効率的・効果的な開発を行うための開発手法の一つである。
用語の意味
- ドメイン
対象となる業務領域 - ドメインモデル
ドメインの問題を解決するためのモデル - ドメインエキスパート
ドメインに詳しい人間 - ドメイン知識
ドメインに存在するルール・制約 - 境界づけられたコンテキスト
あるモデルを同じ意味で使い続ける範囲 - ユビキタス言語
開発者だけでなく、ビジネス側の人間と共通して使う言葉 - 戦術的設計パターン
エンティティやリポジトリなどを使った具体的なソフトウェア設計
モデルには以下の種類がある
- ドメインモデル（ドメインの問題を解決するためのモデル）
- データモデル(データの永続方法を決めるためのモデル)
ドメインモデリング → 実装 → 戦術的設計パターンにリファクタリング
ドメインモデリング
- RDRA(リレーションシップ駆動要件分析)
- ICONIX
上記方法がDDDと相性が良いとされている。
また、ユースケース図とドメインモデル図を使ってモデリングを行うとスタートしやすい。
DDD固有のモデリング手法
集約について
強い整合性が必要なオブジェクトは１つの集約にまとめる。
集約ごとに親となるオブジェクトを決め、「集約ルート」と呼ぶ。
１トランザクションによって集約内のオブジェクトは全て更新される。
境界づけられたコンテキスト
境界づけられたコンテキストは範囲の定義であり、この範囲内ではモデル、言語を統一する。
基本設計
ソフトウェアは高凝集・低結合を目指すと特性が改善するとされている。
凝集度と結合度は「モジュール」単位（機能をひとまとめにした単位）で考える。
高凝集な実装の特徴
- クラス名が「何をするものなのか」が明確である
- クラス名と関連が明確なデータ
- クラス名とデータと関連が明確なメソッド
上記の項目を満たすと、可読性や保守性が高まる。
低結合な実装
２つのメソッドで、一つのメソッドの結果がもう一つのメソッドの内部状態に依存しする状態は高結合となる。
２つのメソッド間の関係を受け渡す引数のみとし、それぞれのメソッドの内部に変更があっても影響を受けない状態にすると結合度は低くなる。
アーキテクチャ
- ドメイン層
ドメイン知識を表現する。ドメインモデルとそれを利用するクラスが存在している。 - ユースケース層
ドメイン層が公開している操作を組み合わせてユースケースを実現させる。 - プレゼンテーション層
アプリケーションの外部との入出力を実現させる。コントローラーや入出力を定義するクラスがある。 - インフラ層
下位のレイヤーで定義されているインターフェイスを実現させる。リポジトリの実装クラスがある。
レイヤードアーキテクチャ
ビジネスロジック層を「ユースケースを実現する層」と「ドメイン知識を実現する層」に分割する。
ドメイン層にリポジトリを置くと、インフラ層に依存してしまうという課題がある。
オニオンアーキテクチャ
レイヤードアーキテクチャを依存関係の逆転の原則によりドメイン層とインフラ層の依存を逆転させたアーキテクチャ。シンプルでDDDに適している。
ヘキサゴナルアーキテクチャ
オニオンアーキテクチャとクリーンアーキテクチャの基本となるアーキテクチャ。
アプリケーションが外とコミュニケーションする際は専用のポートとアダプターを作成して通信させるという思想。
クリーンアーキテクチャ
ヘキサゴナル、オニオンやその他のアーキテクチャの概念を結合しようとしたもの。
参考
「ドメイン駆動設計 モデリング／実践ガイド」