初回のチャプターは「ドメイン駆動設計とは」、「ドメインとは」といった概念を説明する内容です。
そのためこのチャプターでは、コードを書いて手を動かすということはしませんので、ご了承ください。

Chapter1 ドメイン駆動設計とは

ドメイン駆動設計とは

突然ですが、ソフトウェア開発はどのような目的で行っているでしょうか。
顧客業務上での課題や問題を解決するために、開発者は日々の開発業務を行っていると言えるでしょう。
もちろん、ただ開発しただけで全く利用されないソフトウェアは価値を創出しません。

では、価値のあるソフトウェアを作るにはどうすればよいでしょうか。

ソフトウェアを開発する際、顧客が従事している新しい分野の内容を学ぶ必要があります。
金融、物流、自動車、医療、建設、etc・・・
質の良いソフトウェアを作りたいと思うのであれば、(ほとんどの)開発者にとって馴染みのない業務特有の知識が必要になることでしょう。さらには、その会社独自のルールなども含まれていることが考えられます。

上記のような業務独自の特性を実装やコードに落とし込むことによって、よりユーザのニーズを満たす開発を行うことを目指すのがドメイン駆動設計です。

ドメインの知識に焦点をあてた設計手法

タイトルの「ドメイン」と「知識に焦点をあてる」という言葉を紐解きます。

ドメイン

「ドメイン」という言葉はシステムエンジニアとして働いている人であればどこかで聞いた事があるのではないでしょうか。ここでは、ドメイン駆動設計における「ドメイン」の意味を理解します。

「ドメイン」は領域の意味を持った言葉です。顧客が従事している業務における領域と言えるでしょう。
例えば、金融では、預金、融資、投資といった業務分野があります。
預金では、お通帳や印鑑、本人確認書類といった手続きに必要なモノが出てきます。これらが金融システムにおけるドメインになります。
その業務分野における、必要な概念のことを指しています。
もちろん、業界や会社が変われば、ドメインは大きく変化すると本書では記載があります。

知識に焦点をあてる

冒頭の内容と少し被りますが、ソフトウェアには利用者がおり、ソフトウェアは利用者のドメインにおける課題解決を行うための手段です。
課題解決するにはドメインの課題はもちろん、それを渦巻く環境や状況を正確に把握し、正しくソフトウェアに落とし込む必要があります。
上記を行うための「知識に焦点を当てる」です。

つまり「ドメインの知識に焦点をあてた設計手法」って？

顧客が置かれている領域(ドメイン)と真摯に向き合い、課題解決をするための設計手法と言えるでしょう。

ドメインモデル

まずは、モデルとは何でしょうか。
ここでのモデルは現実の事象、あるいは概念を抽象化した概念を指します。

金融業界のお通帳で考えてみます。
金融業務を考慮する上で、お通帳は「入出金の履歴情報を持つ」という特性は持っているでしょう。誰のデータなのかを紐づけるために「特定個人と結びついていること」も必要でしょう。

「お通帳が紙でできている」という特性はどうでしょうか？
業務を進める上では必要なさそうな気がします。
システムで通帳のデータを考慮する場合、お通帳が紙なのか、再生紙なのか、プラスチック(?)なのかは関係ないですよね。「紙でできているから〇〇の処理が必要」なんてことを考慮した実装はしないと思います。

特性	開発において考慮が必要か
入出金の履歴情報を持つ	必要
特定個人と結びついていること	必要
お通帳が紙でできている	不要

上記のようにシステムを構築する上で考慮が必要なものだけを抽出する作業をモデリングと言います。
さらに、モデリングされたことによって、出来上がった概念をドメインモデルといいます。

ドメインモデルは最初からこれだ！と決まったものがあるわけではありません。
各ドメイン、環境、会社によって、ドメインモデルに必要な情報は変化します。

ドメインの住人(つまりはユーザ)の知識はそのドメインにおいて、右に出る者はいないでしょう。しかしながら、システム開発における知識は持っていません。
逆に、開発者はシステム開発のプロです。開発での重要なポイントや要点は分かっても、ドメインのすべてを理解するのは難しいです。

ドメインモデルのモデリングはドメインの住人と、開発者が密に情報連携、意識共有することによって見えてきます。
これは、システム開発において当たり前のことです。
要件定義で顧客の必要としているものを明確にしようとすることは、基本的にどこの現場でも行われているはずです。
ドメイン駆動設計はこの当たり前を行うためのプラクティスとも言い換えることができます。

ドメインオブジェクト

先ほど出てきたドメインモデルは抽象化されたドメインの概念でした。
このドメインモデルをコード化したものがドメインオブジェクトです。

モデリングでも少し出てきましたが、なんでもかんでもドメインオブジェクトとして定義して良い訳ではありません。
開発者は本当に役に立つドメインモデルのみを、ドメインオブジェクトとして扱い、ソースに落とし込む必要があります。
利用されないドメインオブジェクトは利用者の問題を解決しないのであれば、ただの徒労になってしまいます。

ドメインモデルをソースに落とし込んで何が良いか

ドメインの状況が変化することはよくあることです。

業務の方法が変わった
この業務なくなった
ルールが変わった

忠実にドメインの特性を落とし込んだドメインオブジェクトは、ダイレクトにその影響を受けるでしょう。
忠実に再現しているからこそ、そのような変化をドメインオブジェクトに伝えるのは簡単になります。

ドメインモデルとドメインオブジェクトの両者を比較すれば、修正箇所は明確になります。
また、ドメインの変更により、ドメインから、ドメインモデルへ、さらにはドメインオブジェクトへとお互い影響し合う状態となります。

本書のゴール(つまりは、私のゴール)

本書はタイトルにもある通り、「ボトムアップでわかる」としており、実践しやすいパターンから学習を進めます。
少しずつ理解できる領域を広げていき、ドメイン駆動設計の本質に立ち向かう準備を完了することをゴールとします。
(私は、手を動かしながら、本書に書かれていることを実践することで、理解を深めます。)