開発(ほぼ)未経験がDDD本を読んだので解説する①

どうも、開発経験はまだ半年も経っていないのですがDDD本を読んでみました
DDDについて、シンプルに解説してみようと思います

詳細について知りたい人は是非本を買って読んでみてください
[エリック・エヴァンスのドメイン駆動設計](https://www.amazon.co.jp/%E3%82%A8%E3%83%AA%E3%83%83%E3%82%AF%E3%83%BB%E3%82%A8%E3%83%B4%E3%82%A1%E3%83%B3%E3%82%B9%E3%81%AE%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88-Eric-Evans-ebook/dp/B00GRKD6XU/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88&qid=1594435900&sr=8-2)

レビューを見ると「日本語がわかりずらい…」と書いてあったりしますが、僕が読んでみた限りそんなことはなかったですｗ
この本を読むと細かいニュアンスの部分まで読み取れるのでかなりおすすめです

#DDDとは
DDDでは**「ソフトウェアの核心にある複雑さに立ち向かう」**が命題となっています
どういう意味でしょうか

ソフトウェアの核心にある複雑さに立ち向かわなくても、ソフトウェアは作れてしまいます
顧客からの要求に答えるための最低限の機能しか持たないソフトウェアでも、顧客から見たら最高のソフトウェアになります
しかし、そのようなソフトウェアは柔軟性が無く、拡張性が無く、泥臭い実装になり、ビジネスとかけ離れたものになります

DDD本は**「ユーザ要求の問題解決にフォーカスした設計パターン」**と紹介されています
つまり、ソフトウェアの独りよがりではなくビジネスに沿ったソフトウェアを作ることによって良いシステムを作る、ということがDDDの目的となっています

良いシステムとはどのようなものなのか、僕なりに考えた例を挙げようと思います

- **どのような要求にも柔軟に対応できること**

柔軟ではないシステムでは要求が神様になってしまい、つきはぎになってしまいがちです
Webページが欲しいと言われたら、要求通りのWebページを作る
確かに要求には答えられますが、将来の予測不可能な要求に備えることが出来ていません
そもそも予測不可能な要求に備えるということ自体があり得ないと考える人もいるかもしれませんが、DDDではある種の解決方法が示されていました
それでも100%解決しているか、と言われれば微妙ですが、少なくとも備えることが出来ていました

- **拡張性があること**

どのような要求にも柔軟に対応できるようにするためには拡張性があることが必須条件です
拡張性がないシステムは無理矢理拡張しようとするといびつな部分が出てきたり、放っておくと勝手に崩壊したりします

- **要求に対するスマートな解決方法がある**

多少手の込んだ、複雑な内容だとしてもシンプルに少ない労力で解決でき、かつシステムを壊さないやり方があるべきです

- **ユーザーにとっても、エンジニアにとっても良い解決方法がある**

ユーザーにとっては良い方法でも、エンジニアにとっては悪い方法だったりすることは良くあると思います
最善策を考える余地を与えることが良いシステムでは必要だと思います


こんなところでしょうか…
いくつか重複する部分もありましたが、僕が良いシステムに求めているものが分かっていただけたと思います
DDDではこれらの要求をある程度保証するやり方を示していました
もしかしたら他に優れたやり方があるかもしれませんが、今のところDDDが最強だと思っています

#レイヤー化アーキテクチャー
レイヤー化アーキテクチャーとは、システムを複数の層に分割することによって責任の分解をしようとするやり方のことです
DDDでは4層に分けられています
![DDDのレイヤー化アーキテクチャー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529608/ca5bb4bd-8bd7-874d-1a42-cc91d8701e41.png)

上から紹介していきます

- **ユーザーインターフェース層**

ユーザーが直接触る部分のことです
Webページ等が該当します

- **アプリケーション層**

アプリケーションが動作する部分のことです
ドメイン層の呼び出しも行いますが、ドメイン層で何をしているかはよくわかっていません
ファイルの吐きだし等が該当します

- **ドメイン層**

ここがDDDで語られている核となる部分です
DDDで出てくる専門用語は全てこの層の中の話だと思ってほぼ間違いないです
業務に関する部分が該当します

- **インフラストラクチャー層**

システムを支える基盤となる部分です
上位の層を支える一般的な技術を提供します
上位の層それぞれと関係がある部分もあります
通信等もこの部分に該当します

DDD本では上記の4層でしたが、他の本では更に細かく分けているパターンもあるようです
どのように分割したとしてもドメイン層の役割さえ保てていれば別に良いと思っているのですが、あまり細かく分けてしまうとレイヤー化している意味が薄くなってしまうので注意が必要です
レイヤー化アーキテクチャーと言えば真っ先に思い浮かぶのがOSI参照モデルですが、実際に広く使われているのはTCP/IP4層モデルです
変に細かく分割してしまうと、混乱の種になることがあるかもしれません

<font color = "red">※注意
レイヤー化アーキテクチャーという言葉をDDDの専門用語として解釈している人が見受けられますが、それは間違いです
レイヤー化アーキテクチャーとは、システムを複数の層に分割することによって責任の分解をしようとするやり方のことを指す、もっと大きなグループのことです
</font color>

#ユビキタス言語
ユビキタス言語とは、プロジェクトチーム内でしか成立しない専門用語のことです
これだけ聞くと「他の人にも伝わるようにもっと一般的な用語を使え！」と思ってしまいますが、それとは少し意味合いが違います

![ユビキタス言語.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/529608/47a9bce0-677f-2b8b-fb75-bca7dff71dc1.png)

**ユビキタス言語とは、エンジニアの持つ技術的な専門用語と、業務に詳しい人(ドメインエキスパート)が持つ業務的な専門用語を紐づけるための専門用語のことです**

DDDでは、ドメインエキスパートと会話する時だけではなく、プロジェクトチーム内ではユビキタス言語を使って会話しないといけません
これによって単語の意味の解釈による誤解がなくなり、よりスムーズに開発をすることが可能になります

当初はプロジェクトチーム内でしか成立していなかった専門用語でも、それが広く使われるようになれば、ドメインエキスパート以外とでも会話ができるようになるかもしれません
それを最終目標にするのは少し違いますが、DDDを進める上で副次的な効果として現れるかもしれません

#まとめ
今日のところは疲れてしまったのでここまでで…ｗ
次回はドメイン層の中身について解説していこうかなと思います


[DDDについてのまとめページ](https://qiita.com/bouitengineer12/items/dbd79df4b58932a9bccc)