今まで何となくで済ませてきたドメイン駆動設計に関して改めて基本を勉強したいと思い、「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」という書籍を手に取りました！
私の備忘録として、勉強になった内容と個人的な感想をまとめています。
あくまでも備忘録なので、詳しく勉強したい方は実際に書籍を手に取ってみてください🙇♀️
第13章 複雑な条件を表現する「仕様」
備忘録
- 仕様とは、あるオブジェクトが評価基準に達しているかを判定するオブジェクトである。
- オブジェクトの評価はドメインの重要なルールなので、アプリケーションサービスに記述することは避ける。
- 一方で、ドメインオブジェクトに記述する場合は、判定内容によってはリポジトリをドメインオブジェクトのメソッドに引数として渡す必要が出てくるので、不適切な記述になることがある。
- 第13.1章に、周辺知識や補足も含めた解説がある。
- リポジトリのメソッドに、重要なルールが記述されないようにする。
- 特に検索処理の場合は、重要なルールがリポジトリの実装クラス（インフラストラクチャのオブジェクト）に漏れ出しやすい。
- 仕様をリポジトリの返却値に対するフィルターとして利用すると、仕様によってはパフォーマンスが悪くなる場合がある。
- ドメインに記述するべきことを守ることを優先しすぎるあまり、システムの利用者にとって不便（データ取得が遅いなど）を強いてはいけない。
- 第13.2章に、周辺知識や補足も含めた解説がある。
ここまでの感想
判定処理をどこに記述すれば良いか迷うこともあるので、簡易かつ少数であればドメインオブジェクトに記載し、複雑な判定があったり判定処理の数が多かったりする場合は仕様として切り出す、みたいな切り分けで進めるのが、今参画している案件では良さそうです。
リポジトリと仕様の切り分けは難しいところですが、パフォーマンスを考慮した結果としてリポジトリにルールが記載されていることもありますね。
保守性と使用性のトレードオフは永遠の課題です。
第14章 アーキテクチャ
備忘録
- アンチパターンにならないために。
- 短絡的な解決を図ったコードは複雑怪奇な進化を遂げて、いつの日か目の前に立ちはだかる、ということを常に心に留めておく。
- いま開発しているソフトウェアがひどく単純なものであるという先入観を捨てる。
- アーキテクチャを利活用することで、ドメイン駆動設計の本質に集中する環境を用意できる。
- 何をどこに記述するかが明確になる。
- ロジックが点在することを防げる。
- ソフトウェア特有の事情からドメインオブジェクトを防衛できる。
- ドメイン駆動設計と同時に語られることが多いアーキテクチャは以下の3つ
- レイヤードアーキテクチャ
- 元々は、層分けについては言及しているが、インタフェースを利用するかは任意である。
- ヘキサゴナルアーキテクチャ
- インタフェースを利用した依存関係の整理にも言及している。
- クリーンアーキテクチャ
- インタフェースを利用した実装方法まで言及されている。
- あの有名な同心円の図の右下に描かれているFlow of controlの辺り。
- レイヤードアーキテクチャ
- ソフトウェアにとって最も重要なことは、システム利用者の課題を解決することなので、それを達成するために最適なアーキテクチャを選択する。
ここまでの感想
私は、ドメイン駆動設計よりも先にクリーンアーキテクチャに出会ったので、その当時はクリーンアーキテクチャについて理解することに非常に苦労しました。
「Clean Architecture 達人に学ぶソフトウェアの構造と設計」は完全に腹に落とし込めているわけではないので、DDDとの関係性を考えながら何度も読み返すこと（と実践）で、さらに理解を深めたいです。
リンク
リンク
以上
