little hands' lab

ドメイン駆動設計を布教したい

非エンジニアの方に「DDDって何なの?」と聞かれたときの説明[ドメイン駆動設計]

この記事はドメイン駆動設計 #2 Advent Calendar 2018の16日目の記事です。

DDD(ドメイン駆動設計)とは何なのか

そもそもDDDってなんなの?ということをちょくちょく聞かれます。
一言で言うと、「開発手法の一種です」ですが、それだと「ふ〜ん」で終わってしまうので、もう少し興味を持ってもらえる回答を考えます。

まず、開発してて何に困るのかがわからないと思うので、そこから説明をします。

非エンジニア向けの説明

開発手法にも色々あり、行き当たりばったりに作ると以下のような問題に突き当たる、ということがよくあります。

  1. 実際の業務をきちんと理解しないで作ったら、
    リリースしてもあんまり使われなかったり不評なものができる
  2. きちんと整理されてないプログラムを書いたら、
    あとから修正するのがどんどん大変になる

DDDは、このの2個とも解決しよう、ということで生まれた設計・開発手法なのです。

非エンジニア向けとしては、だいたい以上です。

エンジニア向けの補足

非エンジニア向けとは書きましたが、上記の内容はエンジニアにも使える説明なので、エンジニア向けにはせっかくなので以下のことを付け加えます。

DDDは、開発手法の中でも「ドメインモデリング」をに着目してソフトウェアの価値を高める手法です。

現実→モデル
が1に対する解決策です。
ソフトウエア化する対象(これをドメインと呼びます)をきちんと理解し、「ドメインモデル」として表現してそれをどんどん改善していくことを目指します。
リリースしてから良し悪しを判断するのだと時間がかかるので、モデル自体をドメインに詳しい人と共有し、モデルの段階で議論してフィードバックを反映することで、短いサイクルでのモデル改善を目指すのが特徴です。

モデル→コード
が2に対する解決策です。
理解したらモデルの知識がコードの中でいろんなところに散らばっていては後から見るのが大変なので、きちんと特定の場所に情報を集約していくアプローチをとります。
凝集度 をあげると一般にコードのメンテナンス性は高まると言われており、それを追求することになります。

なんか聞いたことある話だぞ

DDDは モデルをコードに落とすのにオブジェクト指向設計の手法を使っている という立場で、オブジェクト指向が普通の人たちからすれば割と普通の考えだったりします。それに加えて、DDD独自のニーズに最適化したデザインパターンを定義しています。

また、現実→モデルという発想も、モデル駆動開発という発想を使っているもので、それはDDDだけのものではありません。その手法が普通の人からしても、これもまた当然のことを言っているように感じるでしょう。

このように、DDDでは既存の様々な手法を統合して、「現実→モデル→コード」を実践することで、ソフトウェアの価値を高めることを目指すものなのです。