主にRails（Djangoでも同じ話だな）での開発を念頭に読んで、気になった点を五月雨に書きます。
Chapter 2. 値オブジェクト
所感
静的型な処理系であれば誤った代入も防げるし、ロジックは集約できるし、価値は理解できるんだけど、ORMと相性が悪そうだなーとは思った。どうしてんだろうな。
Chapter 4. ドメインサービス
所感
各機能に必ずドメインサービスを作りましょうみたいなSIerな考え方だと小規模サービスではかなり窮屈で開発効率が悪くなりそう。 基本的にはモデルに業務ロジックを集約しつつ、モデルをまたがるような処理はドメインサービスに書くのが良さそう。
さすがにコントローラーに長大なロジックを書くことはないんだけど、モデルは大きくなりがちだと思う。理由としては以下が挙げられる。
- DBの正規化が不足していてフィールドが多すぎる
- モデルにまたがった処理が書かれている
後者の場合はドメインサービスの概念を導入してやるとうまくいくんでしょう。
「業務を表現したものではなく、アプリケーションを作るために必要なのであれば、アプリケーションサービスに書くべき」とのこと。メール送信とかはどうなんだろうな。
Chapter 5. リポジトリ
データの永続化を担当。
所感
Railsだとアクティブレコードがあるから不要なようにも思った。
Chapter 6. アプリケーションサービス
ユースケースを実現するためのもの。
所感
MVCアーキテクチャのコントローラーか、バッチ処理のエントリーポイントかな。
アプリケーションサービスがドメインの振る舞いを呼び出せてしまうと、各所にロジックが散らばってしまうので、データを詰め替えるべきとの主張だった。大規模アーキテクチャにありがちなルールだなぁ。
6.4. 凝集度
すべてのインスタンス変数はすべてのメソッドで使われるべき。一部のメソッドでしか使われない変数があるのであれば、クラスとして切り出すべき。
所感
あまり考えられていなかったので、意識したい。モデルやコントローラーのクラスは凝集度が低くなりがちだとは思う。
Chapter 7. 依存関係のコントロール
本来、DBアクセスなどの低レベルモジュールに高レベルモジュールが影響を受けるべきではない。永続化方法はドメインに関係がないはずである。インターフェースを宣言し、低レベルのモジュールはそのインターフェースに合わせて実装することで、依存関係を切り離すことができる。
ここで問題になるのが実装クラスをどうやって作るかだが、DI Containerを使うと良い。
所感
例示されたケースだと、リポジトリ入れ替え可能になるのでテストが楽になるよ、とのことだったが、Railsの場合は本物のDBに向かってテストを実行して大きな問題は感じていない。。。
Chapter 9. ファクトリ
ただ漫然とnewするのではなく、ファクトリを導入すべきか検討する習慣をつけるべき。
所感
これはまあおっしゃるとおりだと思った。
Chapter 12. 集約
集約の外部から教会の内部のオブジェクトを操作してはいけない。集約を操作するための直接のインターフェースとなるオブジェクトは集約ルート（Aggregate Root）と呼ばれるオブジェクトに限定される。
所感
自分の想像していた「集約」とは違った。集約ルートの考え方は良いと思った。ただの代入であっても、それにどんな業務的な意味があるのか、あるのであればメソッドにくくることを検討する習慣を持ちたい。
おしまい
Railsだったらどうするかなーと考えながら読んだ。大前提としてドメイン駆動設計をちゃんとやらなければいけないケースでは静的型が必要で、Railsはドメイン駆動設計には不向きなんだろうと思う。
RubyやPythonなどの動的型付け言語に慣れ切ってしまったところにこの本を読むと、静的型付け言語を使いこなす自信がなくなってくる。ある程度静的型付き言語に慣れた後に読み直すとまた感じ方が違うんだろう。
実際の開発では何らかのWebフレームワークやORMに乗ることになるので、そのフレームワーク流儀に従ったうえでDDDを適用していくんだろう。
「実践ドメイン駆動設計」から学ぶDDDの実装入門 CodeZine Digital First
- 作者:WINGSプロジェクト 青木淳夫
- 発売日: 2019/05/31
- メディア: Kindle版
