こんにちは、新卒の小林です。
とある日に上司からこの本を渡されました。
"Domain-Driven Design"..?
そして数ページ見た後、1ヶ月ほどデスクの脇で眠らせていました。
..今回はDomain-Driven Designに関して少し理解できれば良いなという趣旨で書いたので、温かい目で見守ってください。
目次
1. Domain-Driven Designとは
とりあえず名前の意味を理解していこうと思います。
最初は何かを作るデザインかと思いました。しかし違うみたいですね。
直訳してみましょう。
又の名を
”ドメインモデリング”
と言うそうです。
..ん、全く分かりません。
それぞれの単語を簡潔に訳すと、
Driven＝駆動型：動力を与えて動かす型
Design＝設計：計画を立てること
URLの一部に動力を与えて動かす為に計画を立てる..（現段階では直訳なので語弊があると思いますが）
まだ全然想像付かないですね。とりあえずひたすら調べていたら気になる単語が出てきたので調べてみました。
何となくこの”ユビキタス言語”が肝だと感じます。
この文ではよく理解できないと思うので、下図に表してみました。
ポイントとしては
- どちらも（Domain expertsとDevelopment team）理解できる設計をする
- 共通化されたチームの言語
共通言語を用いてより良い・深いモデルを探求する、ということでしょうか。明確なメリットがまだ分からない為、漠然としています..。
結論はチーム内で共通化された言語をチームが持つことで翻訳コストが減りより良いものが作れるみたいです。
ここで一つ疑問が浮かびました。例えば、
↓
技術者はかなりの労力を伴う?
この点を考えると、Development teamだけではなくDomain expertsも同様に労力を使うように感じます（互いに理解し合う為）。従ってDevelopment teamだけの思想ではない事が理解できます。
興味が出てきたところで、更にDomain-Driven Designの概要に触れたいと思います。
2. Domain-Driven Designの概要
ここで大まかにDomain-Driven Designについてまとめていきます。
勿論、言語では無いことがわかりますね（また思想か..この界隈が一種の宗教のように感じます）
略称として"DDD"と呼ばれているそうです。
この思想の内容としては、
↓
それらの集大成として完成した、1つの設計思想又は哲学
..何となく理解してきました。簡潔にDDDの根幹となっているものは
- オブジェクト指向
- エクストリームプログラミング
の2つのようですね。この二つをソフトウェア開発に取り入れ、エリック・エヴァンスとオブジェクト指向コミュニティの実体験をぶち込んだものがDDDと呼ばれています。上記の2つをまだ意味を理解していないので調べてみます。
3. オブジェクト指向とは
オブジェクト＝直訳すると”物”
..モノ指向。
今後は色々と直訳せずに感覚でワードを捉えることにします。
色々と調べた結果、このようにまとまりました。
↓little more detail
”物”を組み立てるように表現して、コンピュータに動作をさせる考え方のこと
↓little more detail
「何が存在して」「それはどんなことができるのか」といったことや、「それぞれの”物”の関係性」を表す
おそらく言葉より図の方が理解しやすいので、図を作成してみました。
例としてEmojiというものが存在し、それはどんな状態なのか、それらの関係性を上図で示しました。"Object of Emoji"を解説すると、
- ”名前、色、歩く速さ”とかの状態（Property）
- ”笑う、歩ける、話せる”とかの振る舞い（Method）
が中に要素として入っていますね。
要するに、
- 動かないで見て取れるもの＝状態（Property）
- 動いた結果分かることや動かないと見れないもの＝振る舞い（Method）
静止させた状態で”見えているもの”と”見えていないもの”の違いですね。
細かいことですが、オブジェクトによって微妙にPropertyとMethodの解釈が異なる気がしますが..、そこに関しては今後更に理解を深めたいです。
上図をjavaで簡単に表してみました。
ふと思ったが、これだと技術者以外の人も何となく理解できるコードになってる（抽象化により自然とユビキタス言語っぽくなる）..。それはさておき、この状態と振る舞いの2点をまとめたものが”オブジェクト”と呼ばれています。
ではこの２点（PropertyとMethod）には一体何の意味があるのでしょうか？重要な点は下記の２つのように感じました（もっとあると思いますが）
- 隠蔽：Methodの"Can talk"はどんなことを話すかを隠している
- 抽象化："Can talk"のように抽象的にまとめることで隠蔽が成立する
*上図参照
うーん、何となく分かるけどイマイチまだ理解しきれませんね。ではこれでどんなメリットをもたらすのでしょうか？
簡潔にいうと
”個別に処理を任せられる”
といったメリットがあります。
例を挙げると下記のようなものです。
↓
先生の仕事：毎朝生徒を”整列”させること
↓
この”整列”をオブジェクトに任せる
（aさんはここに並んで、bさんは3列目の何番目に並んで、等の指示をオブジェクトに任せる）
↓
先生は”整列”という指示を独立したオブジェクトに伝えることで、1人1人に指示を出さなくても整列させることが可能になる
指示する手間が省けるのは良いことですね。
このほかにも
- 先ほど説明した抽象化と隠蔽によりデータの破損が少なくなる
- 汎用的（クラスは再利用可能）
というメリットがあります。このほかにもメリットがあると思いますが、今回はこの辺にしときます。
4. XP（エクストリームプログラミング）とは
総称として”XP”と呼ばれているみたいですね（以下XP）調べた結果をまとめると、
- アジャイル開発手法の1つ
- 反復的に少しずつ開発を進行させていく
- XPの特徴は”5つの価値”と”12のプラクティス”が定義されている
のような感じでした。
xdの”5つの価値”と”19のプラクティス”に関してはこちらをお読み下さい（実践したことがないので深く説明できません）。
図の方が理解しやすいですね。
引用元:wikipedia 
とりあえず従来の方法とは異なりプロジェクトをガンガン進めていくものなんだなあ（かなり語弊を招くと思いますが）、と理解しておきます。
5. Domain-Driven Designのフロー
実装までの流れを簡潔に示すと、
↓
”ドメインモデル”を構築し
↓
それをコードとして実装
のような流れですね。
”ドメインモデル”に関してうっすらとしか理解がないので、まとめてみます。
- 状態や振る舞いを抽象化したもの（上記を参考に）
- ユビキタスな言語であるべき
Development teamとDomain expertsでユビキタス言語を使用しドメインモデルの理解を深める＆構築し、実装することが大事なんですね。
6. 感想
今回はDDDの根幹の１つであるオブジェクト指向を中心に学習しました。感じたことは、
- 従って基盤作りが最も重要
- 技術的な解決よりかは複雑性をどのように解決するかを教えている哲学
正直、まだ原本を読破していないので全然理解しきれていません。その点ご了承ください。
7. ベトナムでAI開発をするならバイタリフィへ
「自社サービスにAIを導入したい」「AIを導入し自社の効率化・コスト課題を改善したい」
という企業様はバイタリフィ・バイタリフィアアジアへお気軽にご相談ください。
当社では『AI導入をお考えの方に精度や効果を無料で確認してから開発の判断ができる』サービス「Mobile AI Lab」を運営しております。
NEW!! 2019.7.19
「業務へのAI導入を検討しているが、何からすれば良いんだろう？」
そんな事業戦略担当者様！
機械学習、ディープラーニングを用いてAIモデルを無料で作成。
AIアプリを気軽に開発できるサービス『Mobile AI Lab』のお問合わせはこちら
