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

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

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

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

第9章複雑な生成処理を行う「ファクトリ」

ファクトリは、オブジェクトを生成する責務を持ったオブジェクトである。
- 複雑なオブジェクトはその生成過程が複雑である。これをファクトリで解消する。
- コンストラクタ内で他のオブジェクトを生成する必要性を考慮するタイミングで、ファクトリに切り出すことを検討する。
ファクトリの存在を開発者に気づかせるためには、パッケージを分割して、ファクトリであることがすぐに分かるパッケージ名をつける。
採番処理に関しては、採番テーブルを用意する方法、DBの自動採番機能を利用する方法、リポジトリに採番用メソッドを用意する方法、の3つが紹介されている。

初めてファクトリが存在している案件に従事した時に感動は、いまだに忘れられません。複雑なオブジェクトの生成処理が分割されているので、ドメインの処理が簡潔になっており、理解しやすかったです。

ただし、ファクトリの存在に気づきづらいこともあるので、パッケージ構成は大事ですね。

コンストラクタ内で別のオブジェクトの生成をするソースコードもたまに見かけるので、そのような場合はファクトリに切り出した方がスッキリする印象です。

第9.3章（ファクトリとして機能するメソッド）に関しては、個人的にはちょっと違和感がありますが、方法としてはありなのかもしれません。

DBの機能でドメインのルールを担保することは避け、DBの機能はサブという位置付けにする。
- 避けるべき例は、ユーザ登録処理においてユニークキー制約を重複チェックの主体にすること、など。

第10章の主題はトランザクションである。
- アプリケーションサービスがインフラストラクチャのオブジェクト（RDBの機能）に依存してしまう問題を解決する方策
  1. C#の場合はトランザクションスコープを利用する。
  2. Javaの場合はAOP（Aspect Oriented Programming）に基づいた@Transactionalアノテーションを利用する。
  3. ユニットオブワーク（オブジェクトの変更を記録するオブジェクト）を利用する。
C#やJava以外の場合は、AOPに基づいた@Transactionalと同様の機能を準備すると良い。

個人的な感想であり、私の慣れの問題も大きいとは思いますが、ユニットオブワークの導入は工数もかかり分かりづらくなる気がしました。

AOPに基づいた仕組みが一番馴染みがあるので、私とは親和性が高そうです。

DBアクセス周りは、気を抜くとサービスやドメインにデータストア関連のソースコードが漏れ出しやすいので、設計の段階で依存関係を解消させたいですね！

リンク

以上