DDD/ドメイン駆動設計を学んでみる（概要理解編）
はじめに
この記事は、筆者自身がDDD（ドメイン駆動設計）について学び、理解を深めるために作成されています。
誤った解釈や表現が含まれる可能性があるため、自己責任においてご参照いただけますと幸いです。
様々な意見や訂正のコメントを歓迎いたします。
DDD（ドメイン駆動設計）とは
DDDはDomain-Driven Designの略称で、ドメイン駆動設計と訳される。本記事では筆者の好みから主にドメイン駆動設計と表記する。
ドメイン駆動設計のコンセプト：
ビジネスの問題を解決するためにビジネスの理解を深め、ビジネスの表現を行う。
つまり、「"ビジネス"と"コード"を結びつけて、継続的かつ反復的な改良を施せる枠組みを作り、ソフトウェアをより役立つものにする」ということ。
なぜドメイン駆動設計が難しいと言われるのか:
ドメイン駆動設計の難しさの１つとして多種多様な専門用語が挙げられる。
ドメイン駆動設計の用語は２つの主要なアプローチに関連する
ドメイン駆動設計において、多種多様な用語が使われるが、それらは大きく「モデリング」と「パターン」という２つの主要なアプローチに関連している。
-
モデリング
ソフトウェアにとって重要な概念の抽出を行うこと、またはその手法 -
パターン
ソフトウェアにとって重要な概念を実装に落とし込むための方法論
モデリングは言葉による説明を理解し、実践を通して学ぶ必要があるが、パターンは詳細なサンプルで説明できるため、学習しやすい。
なぜドメイン駆動設計を採用するのか
先述したように、ドメイン駆動設計（DDD）のコンセプトは、「ビジネスとコードを結びつけ、継続的かつ反復的に改良を施すことで、ソフトウェアをより役立つものにする」というものである。では、なぜこのアプローチが重要なのか。
ソフトウェア開発において、ビジネスの問題を解決することが最大の目標である。しかし、ビジネスの要件、つまり顧客のニーズは常に変化し続ける。ニーズの変化に対応できないソフトウェアは、すぐに陳腐化してしまう。このような状況では、ソフトウェアが長期的に役立つことは難しい。
ドメイン駆動設計を採用することで、ビジネスに対する理解を深め、その理解を反映したソフトウェアを構築することが可能になる。これにより、ソフトウェアはビジネスの変化に追随し続け、長期的に価値を提供できるものとなる。
そもそもドメインとは
ドメイン＝領域（和訳）
ドメイン駆動設計における「領域」は、ビジネスの問題を解決するためにプログラムを適用する対象となる領域を意味する。
そしてここで重要となるのは、「ドメインが何か」ではなく、「ドメインに含まれるものが何か」である。
「ドメインに含まれるものが何か」を理解する
例として、「学校管理システム」と「飲食店予約システム」の２つのシステムを考えてみる（少し雑ですが笑）。
学校管理システムのドメイン
学校管理システムのドメインは、学校運営に関わる領域である。
このシステムが扱うドメインには、以下のような要素が含まれる（あくまで一例）。
| ドメイン要素 | 内容 |
|---|---|
| 学生 | 名前、学年、成績、出席記録などの情報 |
| 教師 | 名前、担当科目、スケジュールなど |
| 授業 | スケジュール、教室の割り当てなど |
| 成績 | 各科目の成績、試験の結果など |
飲食店予約システムのドメイン
飲食店予約システムのドメインは、飲食店の予約と顧客管理に関わる領域です。このシステムが扱うドメインには、以下のような要素が含まれる（あくまで一例）。
| ドメイン要素 | 内容 |
|---|---|
| 顧客情報 | 名前、連絡先、予約履歴など |
| テーブル | テーブル数、配置、空き状況など |
| 予約内容 | 予約日時、人数など |
| 支払い | 支払い方法、キャンセルポリシーなど |
このように、学校管理システムや飲食店予約システムというシンプルな例でも、ドメインに何が含まれているのかを考える必要が出てくる。
ドメインが何を含んでいるかを理解することで、システムが何を扱うべきか、どのように設計するべきかが明確になる。
ドメイン駆動設計ではドメインのモデルを作成する
ドメイン駆動設計におけるモデルとは、「現実の事象・事物を抽象化したもの」を指す。
事物の例としてペンを考える。学校に通う生徒にとってペンは文字を書くための道具であり、一方で文具屋にとってはペンは商品である。
前者は文字が書けることが重要であり、後者は商品としての値段的な価値が重要である。
このように、同じ対象物でもその対象物に対する見方が異なることがある。この見方をモデルとして表現することが重要である。
こうした事象や事物を抽象化する作業をモデリングと呼び、モデリングによって得られたモデルをドメインモデルと呼ぶ。
ドメインモデルの前提
前提として、ドメインモデルは始めから存在するわけではない。
ビジネスサイドはドメインの概念について知識を持っていても、ソフトウェアにとってどの知識が重要かわからないため、それをソフトウェアに落とし込むことは難しい。
一方で、開発者はソフトウェアにとって重要な知識を判別できても、ドメインの概念についての知識がない。
したがって、ビジネスサイドと開発者の両方が協力してドメインモデルをつくりあげる必要がある。
ドメインモデルはドメインオブジェクトとして表現される
ここまで説明してきたドメインモデルは、あくまでも概念を抽象化した知識の状態に留まっている。
よって、これをソフトウェアで扱うために、具体的な形に落とし込む必要がある。
プログラムの適用対象となるビジネスの領域であるドメインを抽象化したドメインモデルを具体化し、実際にプログラムに適用してソフトウェアで扱えるようにするための媒体がドメインオブジェクトである。
ドメインオブジェクトの実装で重要なこと
ドメインモデルをドメインオブジェクトとして表現する際には、「どのドメインモデルをドメインオブジェクトとして表現するか」という選択が重要である。
ドメインモデルは真にユーザーの課題解決に役立つものを選択しなければ、いくら時間をかけてドメインオブジェクトとして実装しても、ユーザーにとって価値のあるものにはならない。
また、ドメインオブジェクトがドメインモデルを忠実に表現していることも重要である。
ドメインに変化が生じた際、ドメインオブジェクトがドメインモデルを忠実に反映している場合、ソフトウェアの変更が容易になる。ドメイン駆動設計の真価は、この変更の容易さにある。
ドメインの概念であるドメインモデルは、ドメインの変化を忠実に受け止めることができる。そして、変更したドメインモデルと変更されてないドメインオブジェクトの差分を比較することで、ドメインオブジェクトに必要な変更箇所が特定しやすくなる。
反対に、ドメインオブジェクトがドメインの概念を変化させることもある。実装されたドメインオブジェクトは曖昧さを排除しているため、ドメインオブジェクトを実装する段階でドメインモデルを見直し、さらにドメインの概念に対する捉え方を変化させることもある。つまり、ドメインオブジェクトの実装によってドメインに対する深い理解と洞察を促すことができる。
まとめ
本記事では、ドメイン駆動設計（DDD）の概要を記述した。
特に、ドメイン駆動設計のコンセプトや、ドメインモデル・ドメインオブジェクトの概要をまとめている。
ここで詳細に触れなかったモデリングやパターンについては、今後の記事で詳しくまとめ、理解を深めていきたい。
参考文献
Discussion