エリック・エヴァンスのドメイン駆動設計 １章輪読会に参加して
輪読会に参加してきました。 ddd-community-jp.connpass.com
刺さった言葉と自分なりの理解ををメモ書き程度に残しておきます。
ドメインとは?
議論の中で以下のコメントが出てきて、いきなり刺さりました。
モデルもそうだけど、ドメイン自体も定義が必要
そもそも日本語化難しいので、自分の中で消化しようとしてあきらめてチーム内でもドメインという言葉で無理やり解決していました。議論では以下のようなものがありました。
- （ソフトウェアの）ドメインの意味
ドメインはプログラムを適応する対象領域であり、どんな対象領域かというと、ソフトウェアプログラムを使用するユーザの何らの活動や関心と関係がある。
例えば、部屋の予約受付システムの場合、どうやったら部屋の予約がとれるか、現在の部屋の予約状況は？、予約をキャンセルするにはどうすればよいか？などが活動や関心になると考えます。
上記の部分が、プログラムを適応する対象領域、すなわちドメインというと理解しました。
また、議論の中で、
「ドメイン」を別の単語に置き換えようとすると混乱の元な気がします
というコメントもありました。置き換えれれば、ドメインではなく、日本語で広まったのでしょうが置き換えられないからドメインのまま広まっているのかもしれません。ある程度ドメインのイメージを自分の中で消化したうえで、ドメインという言葉を使っていこうと思います。
また、上記で懸念されるのが、自分の言っているドメインと相手の言っているドメインの意味に齟齬がある場合があると思われるので、気を付けて話をしたいと思いました。
ドメイン設計とドメイン駆動設計の違い
（エヴァンス本では）ドメイン設計とドメイン駆動設計は明確に別の意味で使ってるように読める
ドメイン設計は、ドメイン駆動設計でなくても必要だと思ってます
この発言はかなり衝撃で意識したこともありませんでした。
ドメインとドメイン分析とドメイン設計とドメイン駆動設計をそれぞれ定義しないと後の話についていけない！という焦りがありましたが、議論の中でその答え（一例？）を書いてくださっていました。
ドメインを分析して、ドメインのあるべき姿を設計するということ。
ドメイン駆動設計は、ドメイン設計を通じて構築されたドメイン知識に基づいて 定義されたモデルと実装を一致させていこう、というアプローチだと理解してます
そして、そうなると分析と設計ってなんだ？？ってなり、分析と設計でググってみると、エヴァンス本のQiita記事が上位にヒットしたのでありがたく拝借し、整理してみました。
エヴァンス本、輪読会、上記の記事を合わせ考えると、私の中では以下のような整理になりました。
| 項目 | 解釈 |
|---|---|
| ドメイン | ソフトウェアプログラムを使用するユーザの何らの活動や関心と関係がある領域 |
| ドメイン分析 | ドメインに関する問題領域を明確にする作業 |
| ドメイン設計 | ドメインに関する問題領域の解決策を導く作業 |
| ドメイン駆動設計 | ドメイン設計を通じて構築されたドメイン知識に基づいて、定義されたモデルと実装を一致させていく活動のこと |
ドメイン駆動設計はドメイン設計に依存し、ドメイン設計はドメイン分析の精度に依存することがわかりました。なので、しっかりとしたドメイン分析なくしてドメイン設計はありえず（ドメインが明確になっていないのに、ドメインの解決策は出せない）、ドメイン設計なくしてドメイン駆動設計はありえない（ドメイン設計ができていなければ、ドメイン知識ができていないため、それに基づいた実装もできない）。
つまりソフトウェアつくる人はしっかりドメイン分析しろと。
私もやっていなかったわけではなかったですが、それは業務の一部というようなとらえ方でしたが、この考え方でいけば、すべての土台と考えられるような気がします。
そして、この考え方はエヴァンス本では以下のように書かれています。
ソフトウェアの核心は、ドメインに関係した問題をユーザのために解決する能力である。 それ以外の特徴はいずれも、どれほど重要だとしても、この基本的な目的を支えるにすぎない。 ドメインが複雑だと、ドメインに関係した問題を解決するのは難しい作業になり、 熟練した有能な人々が集中して取り組まなければならなくなる。
私なりの意訳： ソフトウェアの真の目的は、ドメインの問題領域を解決することです。
開発者はビジネスの知識を積み重ねるべく、ドメインに没頭しなければならない。
私なりの意訳： ドメインの問題領域を解決するためには、しっかりとドメイン分析して
モデリングスキルを研ぎ澄まし、ドメイン設計に精通することが要求される。
私なりの意訳： それに基づいて、ドメイン設計しないと駄目だよ
前よりは少し理解できた気がしました。
ちなみにエヴァンス本の続きは、耳が痛い話で、
しかし、たいていのソフトウェアプロジェクトでは、ドメインに関係した問題の解決が重要視されない。 有能な開発者のほとんどは、自分の手掛ける特定のドメインについては勉強する気があまりなく、 ドメインモデリングのスキルを真剣に伸ばすつもりはさらにない。 技術志向の開発者は、自分の専門スキルを発揮できる、定量化可能な問題を楽しむものだ。 ドメインに関する作業は面倒なうえに、入り組んだ新しい知識を大量に必要とするが、 そうした知識は開発者にとって、コンピュータ科学者としての能力を向上させるものではないように見えるのだ
私なりの意訳：
ほとんどの開発者はドメイン分析やドメイン設計に興味はない。
なぜなら、これらの作業は開発者の本業じゃないと思っているし、楽しくないし、スキルが発揮できないし、スキル工場にもならないと思っている。
これが本当だとすると、
ソフトウェアの核心は、ドメインに関係した問題をユーザのために解決する能力である。 それ以外の特徴はいずれも、どれほど重要だとしても、この基本的な目的を支えるにすぎない。
にあるように、ソフトウェアの核心部分をおざなりにして、基本的な目的をささえるものに熱をあげているということになります。結構ショッキングでしたが、肝に銘じました。
ドメインとビジネス,業務知識の違い
「ドメイン知識」と「業務知識」も、また not equals なんじゃないかと最近思い始めてたり
ドメイン知識 == 業務知識 だとしたら、最初から「業務知識」って書きますよね
この辺りはまだ自分にはよくわかりませんでしたが。
gitやsvnのドメインは、雑に言うと「バージョン管理」になると思いますが、それはいわゆる「ビジネス」とは呼ばれませんよね
業務ソフトウェアだけがソフトウェアではないし、すべての人がビジネスにしか興味がないわけでもない
は後々納得感を助けてくれると思いますので、書き残しておきます。
ドキュメント残す、残さない問題について
完全に私の意見ですが、
仮に、ドメイン設計およびドメイン駆動設計によりコードなどの落とせたと仮定して、
解決領域のみが成果物に落ちる形となると考えました。
そうなると、問題領域、つまりドメイン分析部分となぜ、そのドメイン設計を選択したか？という情報については成果物には残らないことが予測されます。
なので、これらの部分は、ドキュメント、人の伝承、成果物に添えるコメントなどで補っていかないと、何に対する解決なのかというものだけが残ってしまい、成果物から問題領域を予測したり、設計の意図を探っていく作業が発生する可能性があると考えました。
輪読会に参加しての感想
- 進行役２名、解説や意見いう方１名で、すすめていましたが、大変バランスがよく聞きやすかった
- ddd界隈で有名な方々が多数参加していてよかった
- 有名な方々がいる中でも、すごい贔屓するわけでもなくバランスよく意見を拾っていてよかった
- タイムキープがすばらしい。終わりがわかっているから集中して聴ける。少し伸ばす場合でも理由を宣言しているので、納得感があった
- 程よく参加者に参加しやすい空気感をつくってくれている。参加してもいいし参加しなくてもいい。そして参加してくれると喜んでくれていたので、参加しやすかった。ちょうどFMラジオのような感覚
