エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう（Eric Evans 牧野祐子 和智右桂 今関剛） ｜ 翔泳社の本
去年の秋ぐらいから設計に悩む事があり、エリック・エヴァンスのドメイン駆動設計、いわゆるDDD本を買ってました。
なかなか通しで読む時間が取れず、気になる所をつまんで読んでたので、ちゃんと理解出来てないなと思っていた所、読書会をすると言う知り合いが居たので混ぜてもらいました。
折角なので記憶に新しいうちにメモして置こうと思って書いてるけど、理解がふんわりしてるまま、もしくは勘違いしたまま書いてる可能性もあります。
あと、議事録ではないので、あくまで読書会で話した結果、自分が思った事を書いています。
なんか書いてたらすごく長くなっちゃったけど、次回以降もこんなに書けるか分かりません。
今回読んだ範囲
- まえがき
- 第1章 知識をかみ砕く
- 第2章 コミュニケーションと言語の使い方
ドメイン駆動設計とは
だが、明確に体系化されてはいないものの、オブジェクトコミュニティの底流として、ある哲学が出現してきている。私はその哲学を、ドメイン駆動設計と呼んでいる。
まえがき
ドメイン駆動設計とは、つまりDDDとは何か。まえがきの、かなり最初に書いてあります。
これはもう、特に書く事もないというか、こっからが理解のスタートって感じです。
モデルとは
気になる所を掻い摘みで読んでて度々疑問に思っていたのが、モデルという用語の意味でした。
何となくは分かっているんだけど、他の事を解説している部分で、文脈上モデルと比べる事で読み取る様な事があると、モデルの理解がふんわりしてるので、理解出来ない。むしろ、モデルってなんだっけ？となってしまう事が何度かありました。
第1章は一応目を通していたはずだけど、改めて読んでみると、ちゃんとモデルとは何かが書いてありました。
とはいえ一言で表せるほど理解してないし、DDD本でも第1章の中で何度もいろんな表現でモデルとは何かを説明してたので、一言で表せるものじゃないのかも。
DDD本の第1章、第2章までの中で見かけたモデルの説明
ドメイン駆動設計は、膨大な知識をかみ砕き、ドメインについての深い洞察と、集中すべき主要な概念を反映したモデルを構築する。
まえがき xv 設計対開発プロセス地図はモデルである。そしてどんなモデルも、現実の何らかの側面や興味の対象となる概念を表している。モデルとは簡素化である。つまり、当面の問題を解決する上で関連する側面を抽象化し、それ以外の詳細を無視することによて行われた、現実に対する1つの解釈なのだ。
P.2モデルとは、選び抜かれてシンプルにされ、意図的に組み立てられた知識の表現形式である。適切なモデルは情報の持つ意味を明らかにし、その情報を問題に集中させる。
P.32. モデルは、チームメンバ全員が使用する言語の基盤である。
P.33. モデルとは、蒸留された知識である。モデルは、ドメインの知識を構成して最も関心のある要素を区別するための、チーム内で取り決めた方法である。我々が用語を選択し、概念を分解して関連づける際に、ドメインについてどう考えることにしたかということが、1つのモデルによってとらえられる。
P.3モデルによってとらえられる知識は、「名詞を見つける」ことに留まらない。ビジネスの活動やルールも、ドメインに含まれるエンティティと同じように、ドメインにとって中心的なのだ。
P.17モデルとは、プロジェクトに携わる人々の頭の中で構築された概念の集まりであり、ドメインについての洞察を反映した、用語と概念間の関係性からできている。
P.23
一言では書けないけど、またモデルがなんだか分からなくなったら、これを眺めたら思い出せるかなって思ってます。
勘違いしていた事
少なくとも第1章、第2章の中では、モデルは業務知識を抽象化した概念のことであって、クラスとして実装されたコードの事ではない様です。
モデルと実装を密接に結びつけるというのが、目指す所みたいなので、実装を指してモデルと言っても差し支えない状態が理想かもだけど、やっぱり概念としてのモデルがあって、実装があるはずなので、モデルと言ったら実装の方を思い浮かべていたのは、勘違いだったなと思います。
ドメインモデルとモデルの違い
もう一つ疑問に思ってるのが、モデルとドメインモデルは違うものとして扱われてるのか、それともほぼ同じ意味で、表記揺れになってるだけなのかです。
こっちは、読んでも判断つかなかったけど、もっと先を読んでる方は、違うものを指してると言っていました。
ちょっと、言葉で説明出来るほど理解出来てないけど、先を読めばそのうち分かるんだろうと思ってます。
ドメインエキスパートは誰なのか
もう一つ言葉の意味・定義の疑問で、ドメインエキスパートがどんな人の事かという話題が出ました。
自分では気にしてなかったけど、言われてみれば確かに説明抜きで登場してる気がします。
受託開発をした経験の中で、業務知識を持ってるはずの発注者がそうかなと思っても、DDD本の中で登場するドメインエキスパートの様なやり取りを、どう考えてもしてもらえる気がしないとか、サービスを自社開発してる企業の場合はだれがドメインエキスパートなのかとか、色々と話をしました。
受託開発でも、自社開発でも、その業務の「エキスパート」はもしかしたら社外の専門家になるのではとか、スタートアップ企業の場合は、誰もエキスパートじゃない状態から手探りで進める事になるといった意見もありました。
色々と話をした中で自分の結論としては、ドメインエキスパートは役割を指しているのかなと思っています。
受託開発の発注者、自社開発だとおそらくは企画とかディレクターとかプランナーとか呼ばれる人がチームに居ると思いますし、スタートアップ企業なら少なくとも創業者が、エキスパートと呼べる程の知識が無いかもだけど、ドメインエキスパートの役割。
そして、ドメインエキスパートの役割の人が、本当に「エキスパート」であればあるほど、良いサービス・製品が作りやすくプロジェクトは成功しやすいって事かなと思っています。
- 受託開発では発注者は、やっぱり自身が日常的にこなしてる業務には詳しいはず。同業他社の業務知識や、社外の専門家では、もしかしたらこの発注者とはやり方が違って役に立たないかもしれない。
- 自社開発でB2Cサービスだと、システムの利用者は社内に居ないけど、プランナーとかがマーケットから読み取った上で企画を立てるという事は、業務知識はプランナーなど企画側が考察を含めながら仮説で作っていく。
- スタートアップ企業では、創業者はたとえ異業種からの参入だとしても、その業界でやりたい事があるから立ち上げると思うので、業界に興味を持っているはずだし勉強もしているはずで、その中で新しいものを作るという事は業務知識にあたるものは、むしろ創業者の頭の中にしか無いとも言えるかも。
さらに、スタートアップや自社開発でも小規模の場合、創業者も開発者だったり、チームメンバー全員が開発者という事もあるかもだけど、それでもマーケットから読み取って、何かを作ってマーケットに出す事を考えるはずなので、それをしてる人がドメインエキスパートの役割になる。
そして多分、小規模だと1人だけが何を作るかを考えて、他は指示を待つなんてやり方じゃないだろうから、多分ほぼ全員がドメインエキスパート兼ソフトウェアエキスパートって事になりそうです。
あと、ドメインエキスパートと対比的にソフトウェアエキスパートという言葉が出てきてるという意見がありました。
本の中でどこの事かはちょっと覚えてないけど、そう言われると、この2者間の対話によってモデリングをしていくというのが、この章の中で語られている事な気がします。
DDDでのモデリングをモデルにしてみた
画像作ってから思ったけど、モデル＝図ではないので、この図がモデルってのはちょっと語弊がありますね。
あと、UMLの細かい書き方をあまり知らないので、矢印とかは使わずただ線で結んでます。
ユビキタス言語が良くわからない
自分も良くわからなくて敬遠していたけど、話し合いでもユビキタス言語良くわからないという人が多く、結構長く話題になりました。
正直な所、今も良くわかっていません。
読む前も読んだ後も、ユビキタス言語は理想論ぽくて現実的じゃない印象を持っています。
何となく目指す所は分かるし、書いてある事が出来たら理想的かなとも思うけど、どうすれば良いのか、どういう用語を使うもんなのか分からないし、DDD本に載ってる例のユビキタス言語を使って、ドメインエキスパートと会話が出来るイメージがわかないです。
経路仕様にある属性をどれか1つでも変更したら、古い輸送日程を削除した上で、経路選択サービスに対して、新しい経路仕様に基づいた新しい輸送日程を生成するよう依頼します。
P.29にあるユビキタス言語を使っての会話例だけど、これで会話出来るとは思えない・・・
ただ、ドメインエキスパートとソフトウェアエキスパートの対話を通じて、モデルを成長させていくとあるし、モデルはユビキタス言語の用語にほぼなるので、話を繰り返す間にモデルの成長と合わせて、そのモデルによって業務知識の理解が深まって、なんだかんだ理解出来るように成長する、みたいな事を言ってる様な気はします。
でも、例えば受託開発で考えた時、ドメインエキスパートである発注者はそんな時間のかかる打ち合わせに、何度も付き合ってくれるのかなと思うと、やっぱり出来そうに無い感がすごいします。
日本語と英語
ユビキタス言語を、対話にも実装にも使うとしたら、日本語と英語の壁はどうするのかと言う話が出ました。
つまり「貨物」がユビキタス言語の用語なら、実装はclass 貨物 {}としなければならないのではないか、とか、DBにテーブルを作るなら日本語が使えないので、ユビキタス言語には「Cargo」を使うべきではないかという話です。
もしくは「Cargo」で対話するのは難しいので、ドメインエキスパートとソフトウェアエキスパートの都合の落としどころとして「Kamotsu」にする必要があるか、とか。
自分としては、ユビキタス言語は対話のツールとして存在していて、業務知識を抽象化した概念を考えながら探る為の道具なので、むしろそんな会話のしにくいルールは、不必要に厳密すぎると思います。
「Cargo」って単語が登場する会話で、概念を考えながら探るという、頭をすごく使うタスクがうまく出来るとは思えないです。
つまりユビキタス言語では「貨物」で話をしてclass Cargo {}と「cargosテーブル」とかで実装をするものと思っていました。
英語圏であれば、全部「Cargo」で良いとは思うけど、日本語圏ではどちらによせても不都合があるし、そこまで厳密にやらなくてもと思っています。
ただ、DDD本の中では、確かにユビキタス言語は補助的なものではなく厳格に使う事を求める表現があったと思います。
日々の議論で使う用語法が、コードに埋め込まれる用語法から切り離されている。
P.25
これが問題であると書いてあると思う。
モデルを言語の骨格として使用する事。チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いることを、チームに約束させること。
p.26
ごく一部を抜き出してみても、厳格に用いるとあるし、コードにまで反映させるべきと言ってるような印象は、確かにあります。
仮に「Kamotsu」の様なユビキタス言語を作り、関係者がそれを理解するなら、例えばオフショアの様な、他言語圏の関係者との共通言語にもなるという意見もありました。
正直、正解が分からないというか、自分の解釈が合ってるという根拠が見当たらずもやもやしています。
ゲーム開発の例
ゲームではパラメーターとして良くある「経験値」だけど、世界観とかの関係で、ユーザーには「訓練度」とか「習熟度」みたいな表現を使ったりする事があります。
例えば、武器を色々選べるゲームでは、武器を使うと武器の経験値が上がって武器が強くなるみたいなシステムあるとします。
具体的なタイトルは思い出せないけど、割とそういうのあったと思う。
| 概念 | ユーザーに見せる用語 |
|---|---|
| キャラクターの経験値 | 訓練度 |
| 武器の経験値 | 習熟度 |
武器にもキャラクターにも、経験値がある様な場合、プランナーと話をする中で「習熟度」と「訓練度」言ったり「武器の経験値」と言ったりすると、割と混乱します。特に「習熟度」と「訓練度」は、開発中のゲーム専用の用語なので、会話では何かと混ざって「上達度」とか「練兵値」みたいな、違う用語を言ってしまったりも、たまにある気がします。
表に既に書いてあるけど「経験値」と言うのは、ゲームでは既に概念になってるはずでプランナーも開発者も「キャラクターの経験値」「武器の経験値」で統一すれば、用語による混乱は避けられると思います。
この例だと分かりやすいかなと思っていて、ユビキタス言語というのは、こういう事なのかなというのが、今の所の理解です。
完全に余談だけど、「キャラクターの経験値」「武器の経験値」みたくどっちも「経験値」だとユーザーに分かりにくいだろうから「習熟度」と「訓練度」みたいな用語を作ってる面あると思うんだけど、もしかして逆に分かりにくくしてるんじゃないだろうか。作ってる方が混乱してるんだし。
まぁ世界観的な意味もあるけど。
B2CでDDDを実践している会社もあるらしい
- チャットワークがScalaを採用する理由、これからのチャレンジ。 | チャットワーククリエーターズブログ
- ドワンゴ吉村総一郎氏「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」@デブサミ2014 2日目 – tchikuba's blog
DDD本の中で出てくる例も受託開発っぽいし、ドメインエキスパートの事もあるので、B2Cの自社開発でDDDを実践するの難しそうと思っていましたが、実践している所はあるみたいです。
これを書く為に上記のリンク先の記事を探してきたけど、まだ読んでないです。
取りあえず、あるんだなぁと言う事で。
DDDが想定するプロジェクトの規模
旧来のウォーターフォール手法では、ビジネスエキスパートがアナリストに話をして、アナリストが噛み砕き、抽象化して、その結果をソフトウェア作成者であるプログラマに伝える。
P.14
この辺から、いわゆるSI業界のような、割と大規模のプロジェクトを想定している様な感じ。引用するほどはっきりした所は他には余り無いけど、何となく大規模な印象を感じます。
でも、DDDでのプロジェクトの進め方として、モデリング・設計・実装を、それぞれの役割の人が順番に進めるウォーターフォールではなく、ドメインエキスパートとソフトウェアエキスパートが試行錯誤でやり続けるイテレーション開発が必要としているし、アジャイルやXPといった単語もあげてる。
アジャイルとかは確か、チームの全員が同じ場所に集まる事を推奨してた気がするので、余り大規模だと難しいような気もするし、大規模想定という訳でもないのかも。
まぁこの辺はちゃんと分かってないので、足りない知識の上での印象ですけど。
開発がイテレーティブである。
開発者とドメインエキスパートが密接に関わっている。
まえがき xv 設計対開発プロセス
いい加減長くなるので、ちゃんと全部引用しないけど、アジャイルとかXPって単語はこの辺で見かけました。
あくまでイテレーション開発の関連として単語が出てただけだけど。
環境？
| 環境 | バージョン |
|---|---|
| エリック・エヴァンスのドメイン駆動設計 | 初版 |
初版だからたまに間違いとかあるっぽいけど、まぁしょうがない。
書いた日
2015年3月10日頃