こんにちは、新卒の小林です。

とある日に上司からこの本を渡されました。

“Domain-Driven Design”..?

そして数ページ見た後、1ヶ月ほどデスクの脇で眠らせていました。

..今回はDomain-Driven Designに関して少し理解できれば良いなという趣旨で書いたので、温かい目で見守ってください。
New11/17(金)IT企業向けベトナム情報満載の無料セミナー(先着50名様限定!東京で開催)

1. Domain-Driven Designとは

とりあえず名前の意味を理解していこうと思います。

最初は何かを作るデザインかと思いました。しかし違うみたいですね。

直訳してみましょう。

Domain-Driven Design=”ドメイン駆動型設計”

又の名を
”ドメインモデリング”
と言うそうです。

..ん、全く分かりません。

それぞれの単語を簡潔に訳すと、

Domain=ドメイン:URLの一部
Driven=駆動型:動力を与えて動かす型
Design=設計:計画を立てること

URLの一部に動力を与えて動かす為に計画を立てる..(現段階では直訳なので語弊があると思いますが)

まだ全然想像付かないですね。とりあえずひたすら調べていたら気になる単語が出てきたので調べてみました。

ユビキタス言語:より良い・深いモデルを探求するために必要なもの

何となくこの”ユビキタス言語”が肝だと感じます。

この文ではよく理解できないと思うので、下図に表してみました。

ポイントとしては

– どちらも(Domain expertsとDevelopment team)理解できる設計をする
– 共通化されたチームの言語

共通言語を用いてより良い・深いモデルを探求する、ということでしょうか。明確なメリットがまだ分からない為、漠然としています..。

結論はチーム内で共通化された言語をチームが持つことで翻訳コストが減りより良いものが作れるみたいです。

ここで一つ疑問が浮かびました。例えば、

開発を理解していないズブの素人(僕のような)に理解できるような共通言語を技術者が使う

技術者はかなりの労力を伴う?

この点を考えると、Development teamだけではなくDomain expertsも同様に労力を使うように感じます(互いに理解し合う為)。従ってDevelopment teamだけの思想ではない事が理解できます。

興味が出てきたところで、更にDomain-Driven Designの概要に触れたいと思います。

2. Domain-Driven Designの概要

ここで大まかにDomain-Driven Designについてまとめていきます。

エリック・エヴァンス氏が書籍にて提唱した手法(2003年)

勿論、言語では無いことがわかりますね(また思想か..この界隈が一種の宗教のように感じます)

略称として”DDD”と呼ばれているそうです。

この思想の内容としては、

オブジェクト指向コミュニティの間で長年培われてきたドメインモデリングのノウハウやベストプラクティス

それらの集大成として完成した、1つの設計思想又は哲学

..何となく理解してきました。簡潔にDDDの根幹となっているものは

– オブジェクト指向
– エクストリームプログラミング

の2つのようですね。この二つをソフトウェア開発に取り入れ、エリック・エヴァンスとオブジェクト指向コミュニティの実体験をぶち込んだものがDDDと呼ばれています。上記の2つをまだ意味を理解していないので調べてみます。

3. オブジェクト指向とは

オブジェクト=直訳すると”物”
..モノ指向。

今後は色々と直訳せずに感覚でワードを捉えることにします。

色々と調べた結果、このようにまとまりました。

ソフトウェアで扱う事柄についてデータと操作(メソッド)をまとめて1つの”物”として捉える


↓little more detail


”物”を組み立てるように表現して、コンピュータに動作をさせる考え方のこと


↓little more detail


「何が存在して」「それはどんなことができるのか」といったことや、「それぞれの”物”の関係性」を表す

おそらく言葉より図の方が理解しやすいので、図を作成してみました。

例としてEmojiというものが存在し、それはどんな状態なのか、それらの関係性を上図で示しました。”Object of Emoji”を解説すると、

– ”名前、色、歩く速さ”とかの状態(Property)
– ”笑う、歩ける、話せる”とかの振る舞い(Method)

が中に要素として入っていますね。

要するに、

– 動かないで見て取れるもの=状態(Property)
– 動いた結果分かることや動かないと見れないもの=振る舞い(Method)

静止させた状態で”見えているもの”と”見えていないもの”の違いですね。

細かいことですが、オブジェクトによって微妙にPropertyとMethodの解釈が異なる気がしますが..、そこに関しては今後更に理解を深めたいです。

上図をjavaで簡単に表してみました。

ふと思ったが、これだと技術者以外の人も何となく理解できるコードになってる(抽象化により自然とユビキタス言語っぽくなる)..。それはさておき、この状態と振る舞いの2点をまとめたものが”オブジェクト”と呼ばれています。

ではこの2点(PropertyとMethod)には一体何の意味があるのでしょうか?重要な点は下記の2つのように感じました(もっとあると思いますが)

隠蔽:Methodの”Can talk”はどんなことを話すかを隠している
抽象化:”Can talk”のように抽象的にまとめることで隠蔽が成立する
*上図参照

うーん、何となく分かるけどイマイチまだ理解しきれませんね。ではこれでどんなメリットをもたらすのでしょうか?

簡潔にいうと
”個別に処理を任せられる”
といったメリットがあります。
例を挙げると下記のようなものです。

小学校の先生が1人

先生の仕事:毎朝生徒を”整列”させること

この”整列”をオブジェクトに任せる
(aさんはここに並んで、bさんは3列目の何番目に並んで、等の指示をオブジェクトに任せる)

先生は”整列”という指示を独立したオブジェクトに伝えることで、1人1人に指示を出さなくても整列させることが可能になる

指示する手間が省けるのは良いことですね。

このほかにも

– 先ほど説明した抽象化と隠蔽によりデータの破損が少なくなる
– 汎用的(クラスは再利用可能)

というメリットがあります。このほかにもメリットがあると思いますが、今回はこの辺にしときます。

4. XP(エクストリームプログラミング)とは

総称として”XP”と呼ばれているみたいですね(以下XP)調べた結果をまとめると、

– 1990年代後半、Kent Beck氏らによって作られた
– アジャイル開発手法の1つ
– 反復的に少しずつ開発を進行させていく
– XPの特徴は”5つの価値”と”12のプラクティス”が定義されている

のような感じでした。

xdの”5つの価値”と”19のプラクティス”に関してはこちらをお読み下さい(実践したことがないので深く説明できません)。

図の方が理解しやすいですね。

引用元:wikipedia

とりあえず従来の方法とは異なりプロジェクトをガンガン進めていくものなんだなあ(かなり語弊を招くと思いますが)、と理解しておきます。

5. Domain-Driven Designのフロー

実装までの流れを簡潔に示すと、

”ユビキタス言語”を用いて

”ドメインモデル”を構築し

それをコードとして実装

のような流れですね。

”ドメインモデル”に関してうっすらとしか理解がないので、まとめてみます。

– DDDはドメインモデルを中心に考える設計
– 状態や振る舞いを抽象化したもの(上記を参考に)
– ユビキタスな言語であるべき

Development teamとDomain expertsでユビキタス言語を使用しドメインモデルの理解を深める&構築し、実装することが大事なんですね。

6. 感想

今回はDDDの根幹の1つであるオブジェクト指向を中心に学習しました。感じたことは、

– 開発の初期段階で成功するか否かが決まりそう(言葉(ユビキタス)を重視した思想だからコミュニケーションが不可欠=初期段階が肝)
– 従って基盤作りが最も重要
技術的な解決よりかは複雑性をどのように解決するかを教えている哲学

正直、まだ原本を読破していないので全然理解しきれていません。その点ご了承ください。

7. ベトナム・オフショアでのFront-end開発なら実績のあるバイタリフィへ

ベトナムへ進出されるならホーチミンで約9年、オフショア開発・アプリ開発を展開しているバイタリフィバイタリフィアアジアへお気軽にご相談ください。

ベトナムでのオフショア開発における『フロントエンド開発』や『アジャイル・スクラムでのサービス開発』も得意としております。またベトナム向けIT・WEBサービス/アプリの開発支援、ローカライズ、テストマーケティングといった進出支援に加えて、日本や他国向けのオフショア開発やアプリ開発も行っております。

New 11/17(金)開催
IT企業のためのベトナム進出セミナー!・ビジネス環境 ・進出方法 ・仮想通貨ソフト開発 ・マーケット開拓事例 開催日 2017年11月17日(金) お申し込みはこちら