ドメインサービスの記事を公開しました
ドメインサービス の記事を公開しました。
DDD を学んでいると、エンティティや値オブジェクトにルールを置く、という考え方は比較的イメージしやすい一方で、「どちらにも自然に置きにくいルール」をどう扱うかで迷いやすいと感じています。
今回の記事では、その置き場所としての ドメインサービス について、基本的な考え方を整理しました。
Kotlin での具体的な実装例は、別のドキュメントとして分けています。
DDD では、ドメインルールをできるだけドメイン層に表現することが大切です。
ただ、実際に実装していると、単一のエンティティや値オブジェクトだけでは判断できないルールが出てきます。
たとえば、ユーザー名がシステム全体で一意かどうか、プレイヤーがすでに別のパーティーに所属していないか、といった判断です。
こうしたルールをアプリケーションサービスに直接書いてしまうと、ユースケースの手順とドメイン上の制約が混ざりやすくなります。
また、同じ判断が複数のユースケースに散らばると、ルールの変更にも弱くなります。
そこで、エンティティや値オブジェクトに自然に置けないドメインルールを、ドメインサービスとして切り出す考え方をまとめました。
ドメインサービスの記事では、主に次の内容を扱っています。
- ドメインサービスとは何か
- なぜアプリケーションサービスにルールを書きすぎない方がよいのか
- 一意性の確認や複数集約をまたぐ判断をどう扱うか
- ドメインサービスを使うべきケースと避けるべきケース
Kotlin での具体的なコード例は、実装例ドキュメントとして分けています。
特に、ドメインサービスを「便利な共通処理置き場」にしないこと、エンティティ自身が判断できるルールまでサービスへ逃がさないことを意識して書いています。
DDD の基本要素から順番に確認する場合は、先に エンティティ と 値オブジェクト を読むと理解しやすいと思います。
そのうえで、複数のオブジェクトをまたぐルールや、リポジトリへの問い合わせが必要なドメイン判断が出てきたときに、今回の ドメインサービス の記事を読み、実装の形を確認したくなったら Kotlinでのドメインサービス実装例 に進む流れを想定しています。
また、ドメインサービスの呼び出し漏れを構造的に防ぎたい場合の応用として、ダブルディスパッチ の記事にもつながるようにしました。
DDD の基本的なドメインオブジェクトを整理するときの参考になればうれしいです。