【永久保存版】中卒で代表取締役な現役エンジニアが教えるDDD

## DDDとは

以下wikipedia参照。

> **ドメイン駆動設計**
（[英語](https://ja.wikipedia.org/wiki/%E8%8B%B1%E8%AA%9E): domain-driven design、**DDD**）とは、ドメインの専門家からの入力に従ってドメインに一致するようにソフトウェアをモデル化することに焦点を当てる[ソフトウェア設計](https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A8%AD%E8%A8%88)
手法である[[1]](https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88#cite_note-millet2015-1)[[2]](https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88#cite_note-vernon2013-2)。[オブジェクト指向プログラミング](https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)に関しては、ソースコード（クラス名・[クラスメソッド](https://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%BD%E3%83%83%E3%83%89_(%E8%A8%88%E7%AE%97%E6%A9%9F%E7%A7%91%E5%AD%A6))・[クラス変数](https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%A9%E3%82%B9%E5%A4%89%E6%95%B0)）の構造と名称がビジネスドメインと一致させる必要があることを意味する。例えばローンの申し込みを処理するソフトウェアには、*LoanApplication*
や*Customer*などのクラスと、*AcceptOffer*や*Withdraw*どのメソッドが含まれることになる。

結論、ざっくばらんにいうと、
**チーム開発のために用いられた保守性を担保するための機構。**
**保守性**とは、役割分担されたクラス設計や構造のことを指しています。

まだモヤモヤしてる感じでしょうか。
それでは、更に深掘りしてみていきましょう。

## MVC構造

DDDのメリットを理解するためにはまずMVC構造の理解、MVC構造に沿ったオブジェクト指向型の開発経験が要求されます。

![6207a8006d126a08b14e1e894a835f19.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125469/63fad8d6-6198-a59a-086a-08f9fe12604f.jpeg)
以下のイメージはJAVAによるMVC構造ですが、言語は関係ありません。
![faq4.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125469/e7fbaecb-851e-5348-f7b5-eeba3fb17652.gif)

極端な例ではありますが車の製造工程をイメージしてみるとわかりやすいかもしれません。
車を作るという要求に対して、同じ工場（プログラムファイル）で処理をすることに変わりはありませんが、それぞれのライン（層）で役割が明確に決まっており、一連の流れ（MVC）を経て、ユーザーへお届けできる状態を作り上げます。

![8ea972ed274192142444d17b76c72e55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125469/df728262-77c2-ab46-14c8-c73a96f68e34.png)
![glossary_manufacturing_outline_01-20190924163331.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125469/4b429f63-004e-e99a-29ef-c78af6091c5c.jpeg)

MVCはこのように役割を分散し、ある種のキャパオーバー（肥大化）を防ぐ構造体のことを表していると言えます。

## MVC + DDD

MVC構造で開発していても機能が重ければ処理する内容も増えるので必然的にcontrollerに処理が密集してしまいがちです。

controllerに処理が集まってくるとなんとかして分散したいと人は考えるようになるわけですが、
経験の浅いエンジニアが真っ先に考えつく方法はcontrollerの処理をviewとmodelに分散させようとします。

controllerに書くようなビジネスロジックをmodel側に書いたり、
controllerで制御するようなものをview側で制御するようになります。

しかしこれは根本的な解決にはならず暫定的な対応に過ぎません。
プロダクトが成長し、機能ブラッシュアップを繰り返すと、分散したはずのcontrollerの処理が増え、再度controllerの処理をviewとmodelに分散させようとするイタチごっこが始まり、後にファットコントローラーと言われるようになるのです。

https://docs.sakai-sc.co.jp/article/software-engineering/what-controller-in-mvc-should-do.html

ここまでプロダクトが成長してくると、もはやMVCの層だけでは足りず
プロダクトの成長に応じて、必要な層をデザインして保守性を高めていくことが求められます。

![デザインパターン.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125469/34e457b5-d1f8-83bd-3a2b-088119f43306.png)

プロダクトというのは基本的に成長するので、最初から王道デザインパターンを当てはめて開発していた方が良いというのが結論です。重要事項ほど先に決めておくお話は有名ですね。

https://www.franklinplanner.co.jp/c_fpl/selfstudy/ss-20.html

また、MVCというのはシステム開発におけるレイヤー設計でデザインパターンとも言われています。

> **デザインとは、単なる視覚や感覚のことではない。
デザインとは、どうやって動くかだ。**

それぞれの空間にどういう責務を担わせ、どうやって動かすかをデザインするのもDDDですね。
イラストレーターやアニメーターの経験がある方は馴染みがあると思いますが、ぱっと見１枚の絵でもその絵は複数のレイヤーによって構成されています。レイヤーをどの粒度で分けるなど明確な決まりはありませんが間違いなく言えることは、全て１つのレイヤーに詰め込むと複雑なマテリアルほど修正が難しくなるということです。

![chapter_06_01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125469/31a49ff2-f5fd-4571-dc50-365ed61eef5b.png)

車の製造工程やイラストの構造を例に挙げましたがDDDは色んな業界で駆使されています。
以上を踏まえ、DDDとは **任意の空間を定めて、空間毎に役割を設定してあげて役割分担できる構造の上でお仕事していこうねー、** という設計手法のことです。

https://zenn.dev/naoki_oshiumi/articles/0467a0ecf4d56a