ドメイン駆動設計入門 第1章 を読んで
本書を読んで理解した内容を、個人的見解と経験則を混えて疑問ベースで書いていく。
ドメイン駆動設計は、以下DDDと呼ぶ。
ドメインとは何か。
ドメインは領域という意味を持つ。
DDDにおいては事業領域、つまりは事業が対象とする領域を指している。
領域という言葉は抽象的で捉えづらい。
実際に対象とするものは課題や事象、物体や概念になるので、ドメイン自体ではなく、ドメインにどのようなものが含まれているかを理解できればいいだろう。
本書では、会計システム・物流システムが例として挙げられていた。
会計システムのドメインには金銭や帳票、物流システムでは貨物や倉庫、輸送手段などの概念がドメインに含まれる。
DDDとは何か。
DDDとはドメインを中心とした設計手法。
ドメインを分析し、重要となる概念を明らかにし、それらをソフトウェアとして適切に表現するための設計手法である。
これにより、ユーザにとって価値あるサービスをつくることを助ける。
大前提として、DDDでは開発の前にドメイン理解が求められる。
ドメインにおける何らかの課題を解決するためには、そのドメインについて深く理解する必要があるからだ。
ドメインモデルとは何か。
モデルは、現実の事象や概念を抽象化した概念。
ドメインモデルは、ドメイン内に登場する抽象概念ということになる。
領域に続いて概念という捉えづらい言葉が登場したが、先ほど例に出した会計システムの金銭や帳票がドメインモデルにあたる。
抽象化とは要するに、現実の事象や概念に対し、どのような属性があり、どのようなことを行えるかを考えるということだ。
物流システムにおけるトラックには速度や積載量などの属性があり、荷物を運ぶことが可能である。現実世界では、色や車種といった属性があるが、物流システムでは重要でないため抽象化の過程で除外する。
このような分析の結果、抽出された概念がドメインモデルとなる。
モデリングは開発者が行うのか。
ドメインの問題を解決するソフトウェアを構築するために、両者（ビジネス分析者・開発者）は協力してドメインモデルを作り上げる必要があります。
ドメインに詳しい分析者と一緒に行うのが好ましい。
開発者のみで行わなければいけないものでは、決してない。
（以下、完全な予想）
また、モデリングに取り組む人数はある程度絞った方がいいのではないかと思う。
議論に参加する人数が増えれば増えるほど統一は難しいため、ドメイン知識を持った何人かでモデルを定義し、周りに展開する形が現実的ではないだろうか。
最終的に、事業全体でドメインへの理解が統一されていれば問題ないので。
ドメイン知識と実装が結びついていない場合、どのような問題が発生するのか。
コミュニケーションミスが発生しやすくなる。
これは開発速度に影響する場合もある。
例えば、物流サービスにおける貨物自動車をAさんは運搬車と呼び、Bさんは貨物車両と呼び、そしてCさんは車両と呼んでいるとする。
事業規模が小さい場合は大して問題にはならないかもしれないが、事業が拡大し貨物列車を扱い始めた際に問題が起こる。
ミーティングにてCさんが「車両には...といった制限を設けることにしよう」と言った場合、AさんとBさんは車両を貨物列車と捉え、本来貨物自動車に設けるべき制限を貨物列車に対して適用してしまう可能性がある。
これがソフトウェアとして実装されてしまうと、問題が発生した時には実装をいちからやり直す必要がある。
実装をいちからやり直すことになったことは経験上ないが、これらを防ぐために脳内で単語の変換をしたり、逐一単語の意味を確認したことはある。
毎度、認識の統一を行うのはあまりにも非生産的である。
単語の変換も慣れれば問題ないが、望むべき状態ではないし、プロジェクトに入ったばかりのメンバーにとっては致命的問題である。
DDDではドメインの理解を統一することで、このような事態を防ぐこともできるのではないだろうか。
上の例は、所謂ユビキタス言語の構築によって解決できそうだ。
DDDが対象とする範囲はどこか。
DDDが対象とする範囲について、本書では明確に述べられていない。
ただ、1章全体を俯瞰してみるとDDDには以下の内容が含まれるのではないかと思われる。
1. ドメインを分析する
2. ドメインモデルを抽出する
3. ドメインモデルをソフトウェアで表現する
4. 継続的にドメインモデルをブラッシュアップする
DDDと聞くと何か技術的で難しいものをイメージしてしまうが、どうやら開発者の関心領域に限った話ではなさそう。
ドメインモデルは途中で変更してもいいか。
変更してもいい。
本書でもエリック・エヴァンスのDDDでも、むしろドメインの解釈は変化していくものだと言っている。
これは初めの解釈が完璧である必要はないという意味でもある。
事業の発展に伴って、それまでの捉え方を変えなければならない場合もある。
勘違いしてはならないのは、ドメインの解釈が変化していないにも関わらず実装だけを変更するのはタブーだということだ。
この本では何が書かれているか。
本書は、DDDにおける実装にフォーカスしている。
ドメインから抽出したドメインモデルをソフトウェアとして適切に表現するための実装パターンやアーキテクチャの話がメインだ。
一応、最後に軽くユビキタス言語やコンテキストマップにも触れられている。
ただ詳細には書かれていないようなので、ドメイン分析やモデリング方法について知りたい場合は他の本を参考にした方が良さそうだ。