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

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

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

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

第7章柔軟性をもたらす依存関係のコントロール

ソフトウェアの柔軟性を保つためには、全てのモジュールが抽象（インタフェース）に依存するように制御する。
- ドメインのロジックが特定の技術的要素に依存しなくなる。
- テスト等も容易になる。
依存関係逆転の原則
- 抽象型は、それを利用するクライアントが要求する定義である。
不具合修正時の動作確認等のために依存関係を変更したい場合、以下の2パターンがある。
- Service Locatorパターン
- IoC Containerパターン
  - DI Containerのこと
- 第7.4章で解説されているように、どちらもメリットデメリットがあるので、プロジェクトに合わせて適用する。

依存関係逆転の原則が、第7.2章、第7.3章で分かりやすく説明されています。

依存関係逆転は、知識としては知っていますし、それに沿うように実装していますが、最近やっと腑に落ちてきた（本当の意味で理解が深まった）気がします。大切なことは何度でも復習したいです。

IoC ContainerはC#の技術要素なので、DI Containerと言われると理解しやすいと思いました。Golangでいうところのwireみたいなものでしょうか。

UIのお話
- CLI
  - グラフィックに関連する処理を実装しなくて良いので、動作させることが容易。
  - コマンドを正確に入力するように要求されるので、誤操作を起こしづらい。
- GUI
C#をベースにして解説しているので、各自の利用環境に置き換えて理解しよう。
MVCパターンのコントローラに、ユーザとモデルの間で受け渡すデータの変換以外の処理が存在する場合は、ドメインの知識やロジックがコントローラに漏れ出している可能性がある。

私はサーバサイドの開発がメインなので、簡単な動作確認は基本的にCLIでパパッとやってしまうことが多いです。

「ドキュメントの類が一切存在しないプロジェクトにおいては、ユニットテストがそのロジックのあるべき姿を語る最後の出掛になるでしょう。」
→ 私も本当にそう思います！

ドキュメントが整備されておらず、ソースコードが複雑で奇々怪々な場合は、ユニットテストのテストコードを解析しています。

もし、ユニットテストが十分に実施されていない場合は、、、腹を括りましょう笑

リンク

以上