## 記事の目的
自分がエンジニアとして働いて一年たった時にいざ転職しようと思い、色々な企業との選考を受けましたが技術的な質問で毎回詰まりまくって恥ずかしい思いを何度もしました、、
ですのでまずはDDD設計の勉強をしようと考え、そのアウトプットとしてQiitaを活用させていただくことにしました。
※ 下記のBOOTHの資料をまとめさせていただきました
何か記事の内容と相違がありましたらご指摘いただけると嬉しいです。
そもそもDDDとは？
Domain-Driven Design (ドメインモデリング)
の略称です。
教材にはこのように記載されています。
DDD はソフトウェア開発手法の一つです。
何らかのアプローチをもって、ソフトウェアを効果的、効率的に開発することを目指すものです。
...何かしらのアプローチ??
かなり抽象的な表現なのでわかりづらいですがより良い開発をするために必要な設計なんですね。
要は
DDD はモデリングによってソフトウェアの価値を高めることを目指す開発手法である
らしいです。モデリングについては次でまとめます。
モデリングとは
モデリングとはモデルを作成する活動であります。
そしてモデルには種類があります。
- ドメインモデル : ドメインの問題を解決するためのモデル
- データモデル : データの永続化方法を決める (永続化方法の効率化という問題解決 を行う) ためのモデル
今回主となるのは「ドメインモデル」になりそうです。
そもそもドメインって何..？
知識、影響、または活動の領域。
(問題領域、業務領域とも訳されます。ソフトウェアが表現する対象。例えば、人事評価システムであれば、従業員や業績が知識であり、目標設定や評価が活動に当たります。)
要はやりたいことを具体化したやつって事かな？
モデルの例
例えば履歴書の要素を考えます。
まず履歴書には
• 名前
• 経歴
• 志望理由 • 顔写真
などの情報があります。
しかし履歴書自体には別の要素が色々含まれています。
• 筆跡、筆圧
• 履歴書のメーカー
• 履歴書を書いた時の気持ち
しかしそれらは開発する上で必要ではないかもしれません。
なので、いらない部分を省いて本当に必要な部分だけを洗い出すことが大事（プロセス）でありその成果物がモデルということになります。
良いモデルと悪いモデル
例として人事担当者の採用管理のモデルの場合を考えてみます。
ざっくりとした仕様としては、
あらかじめ求人のデータが存在し、それに対して応募者、採用選考のデータが登録されます。
採用選考のデータはステータスを持っており
書類選考→ 1 次面接→ 2 次面接→最終面接→内定
という風に選考が進むにつれ変更されます。
このモデルをもとに実装したところ、以下の問題が発生しました。
• 書類選考の前に面談があるのに、設定できない
• 面接は3次、4次もあるのに、追加できない
• 求人関係ない応募も許可したいのに、設定できない
この問題に対して上記のモデル設計では解決ができそうにありません。
どうすればこのような問題に対して解決できるモデル設計を行うことができるのでしょうか？
- ドメインエキスパートと会話する
- 運用して得られた発見をモデルに還元する
書籍にはこの２つのアプローチがあると書かれています。
1.ドメインエキスパートと会話する
まずは採用管理のアプリケーションを作るのであれば、その道のプロ、つまり人事担当者に話を聞くことが大事。
（つまりドメインエキスパートとはその使用について専門的に仕事している人のことですね）
これにより、求められているものと実装内容のすれ違いが防止でき、認識違いによる大きな修正コストがかからなくなる。
2.運用して得られた発見をモデルに還元する
１の「ドメインエキスパートと会話する」をやっていたとしても、実際に世に出してみたら改善点があった！とかは必ず起こるのでその発見をモデルに反映していく。
なので重要なのは
「最初からモデルは完成せず、徐々に改善していくもの」
という考えを持っておくことが大事。
逆にいうと最初にモデル設計をする際は改善可能なモデル設計をする必要があるってことですね！
問題解決力の高いソフトウェアを実現するためには、
1. ドメインについての理解を深め、モデルを継続的に改善する
2. モデルを継続的にソフトウェアに反映する
これを常に行い続けることが必要です。
モデルの継続的な改善
ドメインエキスパートと共にモデルを探求する
要は常に改善点を見つけ出し、考え続けるということですね。
ユビキタス言語の使用
ユビキタス言語というのは、開発者だけではなく、ビジネス側の人が見たとしても理解できる厳格に定義された共有言語です。
まぁ簡単にいうとあるプロジェクトで「プラグイン」とか言えば開発者もビジネス側もなんのことだかすぐに分かるみたいなやつですね。
ユビキタス言語で重要なのは
どこでも同じ言葉を使うことで、言葉の変換を極力なくすこと
ですね。
あっちはプラグインとか言ってて、こっちは追加機能とか言っててどっちか統一しろよ〜分かりずらいわ！！てなるからです。
境界づけられたコンテキスト
コンテキストの意味って結構曖昧で分かりずらいんですけど
とりあえず和訳すると
文脈・脈絡
という意味です。
ググりまくっていくうちに理解しやすかった説明があったので載せておきます。
例えば家族同士でお互いの名前を呼ぶ場合、名字を使う事はまずありません。
それは名字が家族にとって自明であり、これをコンテキストとしているからです。
いわばそのコンテキストはその内での共通している部分という意味かなと思います。
「境界づけられたコンテキスト」とは、同じ意味で使い続ける範囲を定義するものです。そうすることにより、 モデルを適切な粒度に分解し、精度を上げることができるそうです。
DDDを取り組む上で重要なこと
課題ドリブン
課題ドリブンとは、解き明かしたいこと・知りたいことをあらかじめはっきりさせるということです。
そもそもなぜユビキタス言語が必要なのか、何を目的として導入するのか、ということを言語化し、認識を合わせることが重要です。
DDDが必要ない課題であったらそもそも設計する必要はないですしね。
小さく始めて、小さく失敗する
1回のモデリング作業だけで完全に目的を達成できるモデルは作れません。モデリングに１週間もかけて完璧を目指すのは得策ではないのかもしれません。
試行錯誤のサイクルを小さくする（常に小さい単位でモデリングしていく）ことにより成功体験が積まれ、スキルアップにつながります。
## まとめ
DDDとはなんぞや？の段階から調べながらアウトプットしていく間に、ある程度「あーこういうことね」と大まかな概要が理解できた気がします。
今回は第１章だけのまとめになりましたが引き続き２章以降もまとめていきたいと思います。