【読書log】ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本：第5章〜第6章

今まで何となくで済ませてきたドメイン駆動設計に関して改めて基本を勉強したいと思い、「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」という書籍を手に取りました！

私の備忘録として、勉強になった内容と個人的な感想をまとめています。

あくまでも備忘録なので、詳しく勉強したい方は実際に書籍を手に取ってみてください🙇‍♀️

第5章 データにまつわる処理を分離する「リポジトリ」

備忘録

• リポジトリは、データストアに関連する処理を集約したオブジェクトである。
  • オブジェクトのデータの永続化（保存）や再構築（復元）などを行う。
    • 第5.8章に例示あり。
    • 永続化の振るまい（SAVE、DELETEなど）は、引数に対象のオブジェクトを取るようにする。
    • 再構築の振るまい（FINDなど）は、識別子によって検索されるメソッドとする。
  • ユーザの重複確認のようなドメインのルールに近い処理は、リポジトリではなくドメインサービスに定義する方が望ましい。
  • リポジトリの実装クラスでは特定の技術基盤に依存した処理を記載しても良い。
• リポジトリを導入することの威力（効果）は第5.2章の例が理解しやすい。
  • ロジックが特定の基盤技術に依存せず、柔軟なソフトウェアの構築に貢献する。

ここまでの感想

初めの方に設計や開発をする機能に関しては、リポジトリについて上記のように考えながら進められます。

しかし、その後は実装済みソースコードの流用の嵐になってしまい、頭から抜けがちです。少なくとも、そこまで深くは意識していないので、反省ですね。。。

書籍では、インターフェースと実装クラスの関係性も、非常に簡潔に記載されていると感じます。

「祈り信者のテスト理論」は笑ってしまったが、割と発生する現象なので笑い事ではない笑

途中でC#固有の表現が割と多く出てくる箇所があったので、馴染みが薄い私にとっては正確な理解がちょっと大変でした。

第6章 ユースケースを実現する「アプリケーションサービス」

備忘録

• アプリケーションサービスは、ユースケースを実現するオブジェクトである。
  • ドメインオブジェクトを組み合わせて、利用者の必要を満たしたり目的を達成する。
• SNSのユーザ機能を例にした、実装の流れ。
  1. ユーザ機能に必要なユースケースを洗い出す。
     • ユーザ情報の登録・確認・更新・退会（CRUD）。
  2. ドメインオブジェクトを準備する。
     • ユーザはエンティティ、ユーザの属性は値オブジェクト。
     • 重複チェックのためのドメインサービス
  3. DBアクセスのためのリポジトリを準備する。
     • この段階では、インタフェースで十分である。
  4. ユースケースに対応する処理を実装する。
     • READ処理では、ドメインオブジェクトを直接返却するか、DTOに詰め替えて返却するかを、プロジェクトでメリデメを勘案して方針を決定しておく。
     • UPDATE処理では、コマンドオブジェクトを利用して、Updateメソッドのシグネチャを変更しなくても良くする手段もある。
• ドメインのルールをアプリケーションサービスに記載しない。
• アプリケーションの凝集度を高めた方が良いかを検討する。
  • LCOMという考え方がある。
  • 凝集度を高める最も簡易な方法は、クラスの分割である。
• サービスは自身の挙動を変化させる目的で状態を保持しない。
  • 第6.6.1章の例が分かりやすい。

ここまでの感想

DTOの考え方もコマンドオブジェクトの考え方も、感覚的にやっていた部分が大きいので、理論と根拠をもとに実装していきたいです。

また、その方が、他の開発メンバーに対しても理解と納得感が得られる説明ができるようになると感じました。

ドメインのルールをアプリケーションサービスに記載しないことは至極当然なのですが、設計の段階では切り分けが難しいことも多そうです。同じロジックが複数の箇所に記載されるようになったら、設計を確認しても良いかもしれません。

LCOMという考え方は初めて知ったので、考慮して開発をしたいです。

以上