最近ドメイン駆動設計について改めて学んでみたので、
仕事で使う時があればすぐに思い出せるようアウトプットしていきます。
1.ドメイン駆動設計とは
2.具体的にどうなるのか
3.作り方（設計編）
4.作り方（実装編）
5.感想
1. ドメイン駆動設計とは
ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）は主要なソフトウェア設計手法の一つであり[1]、ドメインエキスパートの言葉に基づき、ドメインにおけるプロセスやルールをよく表現したドメインモデルを構築し、それに基づいてソフトウェア開発を行うことに主眼を置くものである[2][3][4]。※Wikipedia参照
画面本位でもデータ本位でもなく、業務（ドメイン）ロジックを重点として設計を行う手法。
2. 具体的にどうなるのか
ドメイン駆動設計（以下"DDD"）を使用していない一般的な開発？としては３層アーキテクチャ辺りがメジャーかなと思います。
そこに業務オブジェクトを追加したものがDDDとなります。
3. 作り方（設計編）
DDDをどのように設計に落とし込めばよいのか、手順としては下記。
①. 業務（要件）理解
②. 業務理解から業務ロジックへの落とし込み・分担（マイクロサービス）
※個人情報でいうと「名前」「住所」「電話番号」などの機能
③. ②で分担した機能毎に必要となる処理（値オブジェクト）をまとめる
※「住所」でいうと郵便番号、都道府県、市区町村など…
④. ②と③の共通処理を考える
4. 作り方（実装編）
設計が終わったら実装に反映していきます。
DDD実装としては下記になります。
①. 設計編②のドメインクラスを作成する
--例（住所ドメイン）
class 住所ドメイン {
ゲッター
セッター
}
②. 設計編③の値オブジェクト（郵便番号や都道府県）を住所ドメインに追加する
--例（住所ドメイン）
class 住所ドメイン {
郵便番号クラス 郵便番号;
都道府県クラス 都道府県;
市区町村クラス 市区町村;
ゲッター
セッター
}
③. 設計編④の処理を各ドメイン・値オブジェクトへ実装
--例（住所ドメイン）
class 住所ドメイン {
郵便番号クラス 郵便番号;
都道府県クラス 都道府県;
市区町村クラス 市区町村;
ゲッター
セッター
住所ドメイン加工処理 {
return hoge;
}
}
class 郵便番号クラス {
郵便番号加工処理 {
return hoge;
}
}
④. ③層アーキテクチャ（主にサービス層）でドメイン・値オブジェクトクラスを呼び出して使用
5. 感想
上記からメリットとしては、処理の重複回避や機能毎で何をしたいのかが分かりやすくなると思いました。
しかし画面本位の設計とは異なり「DDDとは何か」がPJ全体が知らないと、
返って複雑なシステムが出来上がってしまう可能性は十分に高いと感じます。
また、本記事ではかなり要約した形で記載をしており、実際にDDDを使用する際には
その他種類のオブジェクトや、そこからの実装パターンの作成を洗い出す必要があり、
設計も関心事で分けて考えたり業務フローを作成したりと考慮する点は多々あるため
一筋縄ではいかないようにも思います。
実装のサンプルにゲッター・セッターを書きましたが、
本来はこちらもあまり好ましくないらしく、まだまだ奥が深いようです…。
(else文回避したりと色々…）
あくまでDDDとしての理想形で、実際にはそうではない混合したものが
現実かなとも思います。郷に入っては郷に従えですね。