ビジネスサイドでもわかる ドメイン駆動設計とは？

ドメイン駆動開発設計について、ビジネスサイドでも理解できるように抽象的な概念を説明します。
エンジニアにとっても、コードの形から具体的に理解するのではなく、一度抽象的な考え方のレイヤーで理解することは理解度の促進につながると考えています。

Transcript

1. ビジネスサイドでもわかる ドメイン駆動設計とは？ だーら（twitter: @3tdara)
2. 自己紹介 - だーら / 設楽広太 - Flamers CTO - VRマッチングアプリ Memoria - VRChatter / 作曲なども - zenn
3. この本がベースです。おすすめ！！ ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 具体的なコードが豊富で実装のイメージがしやすい。 具体を理解してから抽象を理解する。
4. ドメイン駆動設計とは？ その前に開発で大切なことは？
5. 速く作ること
6. 速く作ること • 速く作る = 新しい機能追加や、変更を素早く行う • 逆にどうだとそうならない？？ ◦ 修正箇所が多い・重い ◦ バグが出やすい • 修正箇所が多い・重い ◦ 何かへの結びつきが強すぎるとき（密結合） • バグが出やすい ◦ 「変更漏れ」があるとき
7. それは分かるけど、解決がむずい。 そんな時に意識するのが、 ドメイン駆動設計。
8. ドメイン駆動設計とは？ - 「ドメインの知識に焦点を当てた設計」 - ドメイン: 事業領域。Memoriaであれば「メタバース」「恋愛」など。 以下の問を考え、 - Q: その作業（ルール）は、事業特有のもの？それとも一般的？ - Q: それぞれは、誰が管理するのが適切なの？ 以下を大切に設計する - 事業領域特有のことを考える人、一般的な作業をする人を分ける。 - 他の人の役割を、有難迷惑に奪わないでね！
9. ストーリーで考える ~古の結婚相談所~
10. 司書 えらい人 利用者担当者 受付係 ▪ 利用者の流れ ▪ 1. まずは市役所に入り、結婚相談課の 窓口で、受付係と話す。 2. 利用者担当者のもとに案内され、色々 情報を伝える。 3. 登録担当者は、えらい人が作ったユー ザーマニュアルに沿って登録をする。 4. 司書が、登録者の情報を新しく倉庫の 書類に書き込む。
11. 以下のセリフは、誰が言ってそうか？
12. 司書 えらい人 利用者担当者 受付係 （書庫を開けて）どの列だったか な？あ、あそこだ、はしごかけて 書きに行こう。 登録をご希望ですね、担当の 者をご案内いたします。 それでは、名前と性別を教え てください。今データベースと 照合しますので。 全ての利用者を見たいのです ね。司書に聞きます。 はい、こちらが一覧です。 利用者には、自分の性別と恋愛対 象の性別を聞く必要があるな。こ れは必須項目にしよう。 プレミアムユーザーってのを作ろ う。お金たくさん払う人。 ユーザー名は2文字以上にしよう。 さすがに1文字だと「あ」とかにされ たらびみょい。 え、全員のデータがほしいっ て、、、 大変だけど取りに行くしか
13. 司書 えらい人 利用者担当者 受付係 登録をご希望ですね。利用者 担当の者をご案内いたしま す。 （書庫を開けて）どの列だったか な？あ、あそこだ、はしごかけて 書きに行こう。 それでは、名前と性別を教え てください。今データベースと 照合しますので。 全ての利用者を見たいのです ね。司書に聞きます。 …はい、こちらが一覧です。 利用者には、自分の性別と恋愛 対象の性別を聞く必要があるな。 これは必須項目にしよう。 プレミアムユーザーってのを作ろ う。お金たくさん払う人。 ユーザー名は2文字以上にしよう。 さすがに1文字だと「あ」とかにされ たらびみょい。 え、全員のデータがほしいっ て、、、 大変だけど取りに行くしか
14. 司書 えらい人 利用者担当者 受付係 ・ドメイン知識を持つ。利用者に関する大切なルールや処理を担当する。 ・大事なロジックはこの人だけが持つ。他の人は毎回聞きに来る。 ~ex~ ・ユーザー名2文字以上のルールを持ち、変更はこの人を通すこと。 ・同じユーザーを何で識別するか？メアド？ ID？重複をチェックするのもここ（厳密には DomainServiceクラス） ・えらい人や司書に問い合わせつつ、登録手続き、退会手続きをこなす人。 ・利用者からの入力をフォーマットを整えて上に伝え、エラーが出たら対処する。 ・働き者に見えつつ、重要なルールや調査は全部上に任せていて脳死してる。 ・この事業独自の処理は実は特にしていない。誰でもできる仕事ではある。 ・まじで右から左に流すだけの人。 ・言われた情報を受け取って担当者に伝えて、返す必要があれば渡されたものを返す ・データを書き込む専用の人 ・やってることは何気にハイレベルで他の人には理解しにくい専門職。 ・本じゃなくて、HDDに書き込むなら解雇。HDDの人もクラウド化したら解雇。
15. もしルールを破るとどうなるか？ ① 同じロジックが複数個所で書かれていた場合
16. 司書 えらい人 利用者担当者 受付係 名前は2文字以上なの！ じゃないと上に繋げない！ 名前は2文字以上でないと手 続き始められません。 名前は2文字以上！！ 名前は2文字以上じゃないと データ保存しないです。 ① 同じロジックが複数個所 で書かれていた場合
17. ある日、えらい人が考え直して、 名前の文字数制限をなくした。
18. 司書 えらい人 利用者担当者 受付係 名前は2文字以上なの！ じゃないと上に繋げない！ 名前は何文字でもOK！ 名前は何文字でもOK！ 名前は何文字でもOK！ ・受付係のロジックに、「変 更漏れ」が生じている。 ・バグが発生。1文字の人 は未だに登録できない。
19. もしルールを破るとどうなるか？ ② 本来「えらい人（ドメイン層）」が管理するべき項目 を別の人が管理していた場合
20. 司書 えらい人 利用者担当者 受付係 名前は2文字以上でないと手 続きを始められません。 ② 本来「えらい人」が管理 するべき項目を別の場所が 管理していた場合
21. 市役所内の担当者に加えて、 公民館にも担当を設置。また、郵送でも登録でき るようにした。
22. 司書 えらい人 市役所内 利用者担当者 受付係 名前は 2文字以上！ ② 本来「えらい人」が管理 するべき項目を別の場所が 管理していた場合 公民館内 利用者担当者 名前は 2文字以上！ 郵送 利用者担当者 （特に何も言 われてない） 郵送担当者にロジックが伝えられ ず、バグ発生。 郵送経由だと1文字で登録可能
23. まとめ - 事業特有のルールが一番大事。それをえらい人（ドメイン層）にまとめよう。 - えらい人に判断を仰ぎ、処理してもらうように、担当者は脳死して動こう。 - （あまり説明できなかったが）データの保存（司書）のやることなど抽象度が低い処 理も、ドメイン層とは切り離す。 これで、正しい役割の人に、重複なく書かれる設計にして、変更に強いシステムを作って いこう！というのが 「ドメイン駆動設計」でした！！
24. エンジニア向け補足
25. アーキテクチャ レイヤードアーキテクチャ ヘキサゴナルアーキテクチャ
26. 依存性逆転の話 - Repositoryなどは、IUserRepositoryなど適切なインターフェースを経由で受け取る - これにより、制御フローでは下 流にあるインフラストラクチャ 層が、ドメイン層やアプリケー ション層などの上流に依存す る