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

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

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

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

第15章ドメイン駆動設計のとびらを開こう

軽量DDDに陥らないようにする必要がある。
- 軽量DDDとは、ドメイン駆動設計に登場するパターンだけを取り入れる手法のことである。
  - 短期的にはプロダクトのコードにある程度の秩序をもたらすので、費用対効果が高く感じられる。
- ドメインの本質に向き合うことの方が大事である。
開発者は、ドメインエキスパート（ドメインの精通者・実践者）と会話をして、知識や問題を理解する必要がある。
- ドメインエキスパートに迎合することとは違う。
- 両者が協力して、ドメインの概念から抽出した知識をドメインモデルとして昇華する。
- 両者が直接会話をする機会を設ける。
ユビキタス言語は、開発者とドメインエキスパート間の会話だけではなく、開発者同士の会話でも利用する。
- あるモデルに対して捉え方が異なる箇所でシステムをパッケージによって分割し、各々の領域内で言語の統一を目指すという考え方が、境界付けられたコンテキストである。
  - 第15.4章に解説がある。
  - パッケージ間で整合性を取るために、コンテキストマップが活用できる。

軽量DDDに代表されるように、得た知識やスキルありきで開発をしてしまう、というのはエンジニアあるあるなのかもしれません。ドメインに限らず、本質は何かということを常に意識して仕事に取り組んでいきます。

ユビキタス言語の策定は非常に大事ですが、日常の業務に押されて後回しになりがちという印象です。

現在は私自身が新規参画者なので非常に苦労しています。これを機に、ユビキタス言語を整理する役目を買って出ても良いかもしれません（が、忙しいので誰かやってくれたら嬉しいなとも思っています笑）。

ここまでの内容を、Visual StudioでC#を利用した開発を例にして、レイヤードアーキテクチャをベースにしたソリューション構成を解説している。
- ドメインレイヤーのパッケージ構成では、ファクトリやリポジトリがエンティティや値オブジェクトなどのドメインオブジェクトのパケージに属している。これは、属性ではなく意味的なまとまりに着目したからである。
プロジェクトを分割する方針は大きく以下の3つに分けられるが、2か3が推奨される（書籍としては3を一番推していそう）。
1. すべてを1つのプロジェクトにする
2. すべてを別のプロジェクトにする
3. アプリケーションとドメインだけ同じプロジェクトにする

パッケージに含める範囲はプロジェクトの途中で変更することが大変なので、決定するのには勇気が要ります。

プロジェクトの分割方針は、公開範囲との兼ね合いもあるので、いつも頭を悩ませます。これも決定するのに勇気が要ります。

もし失敗したらどうしようという不安もありますが、その不安を乗り越えてこそ、エンジニアとしてひいては人間として成長できるのだと思っています。

ドメイン駆動設計の基本を勉強したことで、現在の業務で携わっているプロダクトの設計に対する理解が深まりました。そのため、自分が実装する際やレビューする際に、今までよりも適切な行動が取れるようになりそうです。

最新の動向も追いつつ、基本は何度も勉強し直してしっかり身につけたいです。また、困ったり悩んだりした時には基本に立ち帰ります。

リンク

以上