【DDD本読書メモ】ドメイン駆動設計とは
最近「ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本」という本を読んでいます。2週目です。
1週目は1人で黙々と読んでいたのですが、理解が不十分だと感じていました。読み返してより理解を深めたいと思っていたところ、社内で輪読会をする話が出たので参加し、2週目を読み進めています。
せっかくなので、理解を深めるために自分なりのまとめをブログに書いておこうと思います。これは自分の理解を深めること、自分がさっと見返すことを目的としています。 より正確な解釈や詳しい話は上記の本を読んでいただければと思います。
また、認識違いがあった場合はご教示いただければ幸いです。
ドメイン駆動設計とは
この記事ではCapter1の「ドメイン駆動設計とは」を読んだまとめを書いています。
ドメインとは
ドメインは「領域」という意味を持った言葉です。ソフトウェア開発におけるドメインは、「プログラムを適用する対象となる領域」のことです。
例えば会計システムの場合、金銭や帳票といった概念が登場します。これらは会計システムのドメインに含まれます。物流システムだと貨物や倉庫、運送手段などの概念が存在し、それらは物流システムのドメインに含まれます。そういった関心事が「ドメイン」に該当します。問題領域、業務領域と捉えるとわかりやすいかもしれません。
ドメイン駆動設計とは
ドメイン駆動設計とは「ドメインの知識に焦点を当てた設計手法」のことです。
「ドメインの知識に焦点を当てる」とはドメインに向き合い、その概念・事象をしっかり理解した上で、問題や問題解決に必要なことを導き出し、それをシステムに反映させることです。
「当たり前では?」と思いますが、当たり前のことを実践することは意外に難しかったりします。「作ったものがユーザーが求めるものではなかった...」というようなことは実際に起こり得ます。
そうした悲劇を生まないための道標としてドメイン駆動設計は有効な手段となります。
ドメインモデルとは
現実世界の複雑なドメインの概念から全てをソフトウェアに持ち込む必要はありません。ソフトウェアではソフトウェアが担う責務に必要な情報を抽出して扱うべきです。こうした抽象化する作業を「モデリング」、抽象化された概念を「モデル」と呼びます。ドメイン駆動設計では、ドメインの概念をモデリングして得られたモデルを「ドメインモデル」と呼びます。
モデリング - 現実の事象・概念を抽象化する作業 モデル - 現実の事象あるいは概念を抽象化した概念 ドメインモデル - ドメインの概念をモデリングして得られたモデル
ドメインオブジェクトとは
ドメインオブジェクトとは、ドメインモデルをソフトウェアで動作するモジュールとして表現したものです。
ドメインモデルは概念を抽象化した知識にとどまります。開発者はドメインモデルから真に問題解決に必要なものを選択し、ドメインオブジェクトとして実装します。
ドメインの概念 <=> ドメインモデル <=> ドメインオブジェクト
ドメインの概念に変化があれば、まずドメインモデルに反映させ、必要に応じてドメインオブジェクトを変更します。また、プログラムは曖昧な表現を受け入れられないため、ドメインオブジェクトを実装する過程でドメインの捉え方の見直しに繋がることもあります。
こうしてドメインの概念とドメインオブジェクトはドメインモデルを媒介に繋がり、お互いに影響し合う反復的な開発が実現されます。
ドメイン駆動設計のパターン
Capter1の終わりには、この本で学ぶドメイン駆動設計のパターンが挙げられていました。こうして俯瞰して見ると理解もしやすく助かります。見返したいのでメモしておきます。
- 知識を表現するパターン
- 値オブジェクト
- エンティティ
- ドメインサービス
- アプリケーションを実現するためのパターン
- リポジトリ
- アプリケーションサービス
- ファクトリ
- 知識を表現する、より発展的なパターン
- 集約
- 仕様
感想
「ドメイン駆動設計」を説明するだけでもいくつかワードが出てきました。1つ1つわかりやすく解説されており、理解しやすかったです。
また、これまで、DDDのメリットといえば
- ドメインの変更をプログラムに反映させやすいこと
- プログラムがドキュメントになること
などと捉えていましたが、「ドメインに向き合い、その概念・事象をしっかり理解した上で、問題や問題解決に必要なことを導き出し、それをシステムに反映させる」 という当たり前なことを当たり前にやるための補助
という認識は薄かったような気がしたので、改めて意義を確認できてよかったです。