「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」を読んだ

DDDについては軽く表面的な部分を齧った程度の知識だったので、いつかはちゃんと勉強しなきゃなーと思ってた。
けどエヴァンス本とかは難しそうなイメージがあってずっと敬遠しちゃってて。
そんなところに、とっつきやすそうな本書を見つけたので読んでみた。

www.shoeisha.co.jp

結果、読んで良かったと思えたので感想やメモなんかを残しておく。

感想

DDDと言うとまずは「ユビキタス言語」とか「境界づけられたコンテキスト」のような用語から始まって、抽象的な話が続くようなイメージがある。

だけど本書はその辺は後回しで、単純な部分から具体的なコードで示しながら説明が進められる。なので、普段コードを書く時に悩んでたこととリンクさせながら読めたので理解がしやすかった。

あと、様々な設計上の判断の指針(何を判断基準にして利用するパターンを選択するかとか)を示してくれつつ、時には判断の難しいこともあるんだと言うことを明確にしてくれているのがとても参考になった。

メモ

以下は個人的に参考になったことのメモ。長!!

  • 値オブジェクト
    • 値オブジェクトにするかどうかの判断基準は「そこにルールが存在しているか」と「それ単体で取り扱いたいか」。
    • 不変オブジェクトなので、メソッドの結果としては新たなインスタンスとして返却する。
    • 値オブジェクトを使うモチベーション
      1. 表現力を増す
      2. 不正な値を存在させない
      3. 誤った代入を防ぐ
      4. ロジックの散財を防ぐ
  • エンティティ
    • エンティティにするの判断基準は「ライフサイクルを持つかどうか」(生成から破棄までの間に変化するものならエンティティ)。
    • ライフサイクルを表現することが無意味である場合には、ひとまずは値オブジェクトとして取り扱う(その方がシステムはシンプルになる)。
  • ドメインサービス
    • 値オブジェクト・エンティティに記述すると不自然になってしまうふるまいを記述するオブジェクト。
    • 値オブジェクト・エンティティとは異なり、自身の振る舞いを変更するような状態は持たない。
    • ある処理がドメインサービスになるかどうかの判断基準は「それがドメインに基づくものかそうでないか」。
      • ドメインに基づくものであれば、それを実現するサービスはドメインサービス。もしアプリケーションを作成するにあたって必要になったのであれば、それはアプリケーションサービス。
  • ドメインモデル貧血症は避ける
    • ドメインオブジェクトに記述されるべき知識や振る舞いがドメインサービスやアプリケーションサービスに記述され、語るべきことを何も語っていないドメインオブジェクトの状態。
    • 振る舞いをどこに定義するか迷いが生じたら、まずは値オブジェクトやエンティティに定義する。ドメインサービスは可能な限り利用しない。
  • リポジトリ
    • 責務はあくまでもオブジェクトの永続化。ユーザーの重複確認のような処理はドメインのルールに近いのでリポジトリの責務としては相応しくない。
    • 永続化のふるまいは永続化を行うオブジェクトを引数に取る。識別子と更新項目を引数にすることはしない。
    • オブジェクトの作成処理はリポジトリには定義しない。コンストラクタかファクトリを利用する。
  • アプリケーションサービス
    • 処理の結果としてドメインオブジェクトをそのまま戻り値とするか否かの選択は重要。ドメインオブジェクトを返すと、アプリケーションサービスの外側でドメインオブジェクトの振る舞いが呼び出されることにより、ドメインに関わるコードが散逸する可能性がある。
    • ドメインオブジェクトの振る舞いを呼び出すのはアプリケーションサービスの役目。
    • 回避する場合は、データ転送用オブジェクト(DTO)にデータを移し替えて返却する。
  • ファクトリ
    • オブジェクトの生成処理自体も、ドメインを表現する層の責務である。
  • 仕様
    • あるオブジェクトが、ある評価基準に達しているかを判定するオブジェクト。
    • ドメインの重要なルールがアプリケーションサービスに記述されてしまうのを回避するために利用する。(=ドメイン貧血症を避ける)
  • アーキテクチャ