ドメイン駆動設計について①
開発をするにあたって設計を勉強したいと思った時に必ずと言っていいほど目にするDDD（＝ドメイン駆動設計）。一体何ものなのかについて何回かに分けて調べたことをアウトプットしたいと思います。
はじめに
私が今回DDDを学習するために用意した書籍が
というものになります。
既に読んでいる方はブラウザバック推奨です。
これからDDDについて学習してみたいという方は購入を検討してみてはいかがでしょうか。
また、当ブログの目的は私が得た知識をアウトプットして定着させることなので、個人的な意見が多分に含まれています（つまり間違っていることもあるということです）。正しい情報が欲しい方は上記や類似の書籍を購入してください。
まずドメイン駆動設計とは？
・高品質なソフトウェアを設計するための手法である。
・高品質とは、”バグのない”ということではなく、”ビジネスとして価値の高い”ソフトウェアであるということ。
うーん、、、難しいですね。ビジネスとして価値のあるものってそれすなわち、アイディアが根本にあるような気がしますが、まだ掴みどころが良く分からないです。
恥ずかしながら、私自身は未だ上流工程の経験がないため、”顧客との折衝”のイメージとしては、
“ある程度経験のあるエンジニアが、とりあえず顧客と話し合いながら要件を纏めて進めていく”
みたいな漠然としたイメージがあります（単に勉強不足なだけ…）
DDDを学習するキッカケとしては、追々携わるであろう業務（上流工程）のために学ぼうと思ったからです。そういう方に見て頂けると同じような視点で見れるのかなと思います。
ドメイン駆動設計を使うことが出来る人とは？
ソフトウェア開発プロジェクトに携わる人全てが対象である
これは意外でしたね。顧客からPM、若手PGに至るまですべての人がDDDに取り組むことが出来るということです。
そんな誰にでも取り組むことが可能なDDD、一体取り組むことで何が変わるのでしょうか。
ドメイン駆動設計を使うと…
・「共通言語」を用いることで、”顧客が開発した”ようなソフトウェアにすることが出来る
・業務知識について深く検討することにより、それらをチーム全体で共有・洗練することができ、ソフトウェアについて理想的な形を構築できる。
・「共通言語」をプログラムとして実装することで、設計がコードとなり、コードが設計となる。また、実装時の課題を設計段階で発見することが出来る。
共通言語とは所謂、ユビキタス言語のことですね。
これら3つがDDDを行うメリットとのこと。顧客・開発メンバーを含めたチーム全体で考えることが出来るようにするため共通言語を用意し、共通言語を用いたプログラムを実装することで、設計自体がすでに実装コードのようなものになっているということでしょうか。
以下、私の解釈ですが
顧客が開発に詳しくなくても、直接ソフトウェア自体に手を加えることを可能にするのが大きな目的の一つであるが、
とはいえ、突飛なことを言われてもシステムに出来ないし開発側も業務理解がないと口出し出来ないので、そのために2点目メリットのように、要件に対する深堀をチーム全体で行い共有することが必要になる。
その結果、3点目のメリットのようにより良い設計が出来たことで実装課題にも早い段階ですぐに気が付ける。
開発側も手戻りなど余計な作業が無くなって、素晴らしいソフトウェアを開発可能にする…
まるで魔法のような気がします。。。
たしかにこのようなことが出来れば、理想的な開発になりそうです。
また、DDDを導入することで複雑なソフトウェアをドメインモデルによって対処することが出来るということです。
DDDでは業務自体をオブジェクトのモデルとして表現する「ドメインモデル」で実装する
要件（仕様）をビジネスロジックとして実装するのと何が違うのでしょうか…。
ドメインモデルは複雑さの中から必要な概念だけを抽出して抽象化されているモデルとのことらしいですが、これはまだピンときませんね。
また、これまではメリットの話でしたが、デメリットもあります。
ドメイン駆動設計のデメリット
30程度のユースケースフローでは、DDDを導入するコストのほうが高くつきます。
なるほど、DDDとはいえ万能ではないということですね。
確かにアプリケーションには単純なユースケースのみの場合や、複雑なケースがある場合など多岐にわたるので、規模によって導入を検討する必要があるので注意する必要がありそうです。
とはいえ少し残念ですね…
あまり読み込めずに区切りも悪かったので、今回はここまでにしたいと思います。
また読み進めた段階で、随時アウトプットしていきます。
それでは。
