アンチパターンといわれようとも、なんとなく楽しいところだけするDDD

ゆるテク なんかそれっぽい勉強会 2025.11

Transcript

1. アンチパターンと言われようとも、 何となく楽しいところだけするDDD 株式会社MICHIRU おーのりょう ゆ る テ ク な ん か そ れ っ ぽ い 勉 強 会 2 0 2 5 . 1 1 2 0 2 5 - 1 1 - 1 7
2. 会社： 株式会社MICHIRU / zeit 自己紹介 マイルール： 正しさよりも、楽しさを おーの りょう 2
3. 3 最近、うれしいこと： 上の部屋のお母さんが、ちょっと良い洗濯ばさみを、 ちょいちょい落としてくる。
4. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 4 今日ですが・・・ 資料の出来が過去一悪いです・・・
5. 催眠商法で学ぶ アンチパターンと言われようとも、 何となく楽しいところだけするDDD 株式会社MICHIRU おーのりょう ゆ る テ ク な ん か そ れ っ ぽ い 勉 強 会 2 0 2 5 . 1 1 2 0 2 5 - 1 1 - 1 7
6. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 6 DDDの思想と雰囲気がなんとなくわかる 今日のゴール まーアレですよ・・・ 内容がひどい言い訳ですよ。
7. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 7 本質を意識するのじゃ この業界は守破離が大事 『規矩作法 守り尽くして破るとも離るるとても本を忘るな』 by 千利休 まずはアーキテクチャや技術を理解し身につける、 その後は自分や環境に合わせてより良い形に変える。 最後は本質を忘れずに、自分なりの新しいやり方を模索 する。
8. DDDって、マジになんなんあれ？ 01 y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 8
9. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 9 DDDって、マジになんなん？ ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）は 主要なソフトウェア設計手法の一つであり、 ドメインエキスパートの言葉に基づき、 ドメインにおけるプロセスやルールをよく表現したドメインモデルを構築し、 それに基づいてソフトウェア開発を行うことに主眼を置くものである。 by Wiki うんっ! よくわからん!
10. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 10 DDDって、マジになんなん？ DDDを理解する上では、ドメインから入らず、 一度『ITエンジニアの仕事の本質』から入ると、 理解しやすいかも。 しらんけど
11. ITエンジニアのお仕事とは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 11 DDDって、マジになんなん？ 仕事：価値を生み出すこと ・世の中の課題を解決させるアイデアを考えた。 ・世の中を変えてしまうような文化や体験を創り出した。
12. ITエンジニアのお仕事とは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 12 DDDって、マジになんなん？ 仕事：価値を生み出すこと ・世の中の課題を解決させるアイデアを考えた。 ・世の中を変えてしまうような文化や体験を創り出した。 作業：価値は生み出さないけど、やらないといけないこと ・マネジメント ・プログラミング ・テスト
13. ITエンジニアのお仕事とは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 13 DDDって、マジになんなん？ じゃ、俺たちがやらなければならないことはなんだ！！
14. ITエンジニアのお仕事とは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 14 DDDって、マジになんなん？ 世の中の情報(社会課題、ビジネス)を解釈し、 そこから価値を創造し表現して世界に届けること。 Information Technology エンジニアリング / アート
15. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 15 ITエンジニア アプリケーション （世の中へのEndpoint） 世の中(現実) 世界は日々変化し 続けている
16. ITエンジニアのお仕事とは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 16 DDDって、マジになんなん？ 世の中の情報(社会課題、ビジネス)を解釈し続け、 そこから価値を創造し表現して世界に届け続けること。
17. ITエンジニアのお仕事とは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 17 DDDって、マジになんなん？ 世の中の情報(社会課題、ビジネス)を解釈し続け、 そこから価値を創造し表現して世界に届け続けること。 変化？ どんど来いっ そう言える仕組みがDDDデス
18. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 18 どーして得意なの？
19. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 19 DDDって、マジになんなん？ 平たく言うと・・・ かなり言いすぎだけど・・・ DDDは現実世界がそのままコードに落ちているため “お前どこ直せば良いんだよ”問題が起きずらい。 (変更容易性が高いシステムになる)
20. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 20 DDDって、マジになんなん？ アプリケーションの変更容易性を高めるには・・・ 実装的アプローチ ・SOLID原則：保守しやすく拡張しやすさを考慮 ・DRY原則：同じことを繰り返さない ・KISS原則：シンプルに保て などなど 設計的アプローチ ・DDD
21. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 21 DDDって、マジになんなん？ 具体的にはドメインを要求、知識、ルールという視点でモデリ ングしたドメインモデルを作成し、このモデルとコードを合わ せることにより、現実世界をそのままのコード化させる。 世の中(ドメイン) 世の中の要求、知識、ルール をまとめたドメインモデル コード
22. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 22 DDDって、マジになんなん？ ドメインとは、アプリケーションが解決したい現実の領域のこと → アプリケーションを作る目的の『対象』 また、このドメインに詳しい人のことをドメインエキスパートと呼びます → 世の中に詳しい人 (神様？？) ドメインとは・・・
23. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 23 DDDって、マジになんなん？ モデルとは・・・ 分かり辛く扱いにくいものを意識したい情報に絞ることにより、 扱いやすくしたもの 地球 面積、場所 地球儀 ジオイド 重力の強さ
24. エンジニアがやるモデリングとは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 24 DDDって、マジになんなん？ ドメインの複雑な情報からエンジニアが扱いたい情報だけを取り 出しモデルを作成することです。 (わかり辛いなら、今回はクラス設計をすると思ってもOK!!) ドメインの構造(OOAD) ドメインの 要求・知識・ルール (DDD) 概念モデル ドメインモデル ドメイン(世の中)
25. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 25 DDDって、マジになんなん？ 世の中、世の中って連呼されても頭に入らない・・・
26. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 26 DDDって、マジになんなん？ 『世の中の情報』とか『アプリケーション』だと抽象すぎて 眠くなるので、夢のない具体的な感じに直します。 世の中の情報 → amazou(甘蔵) もともとネットで甘味を売っていたが、 最近では甘味以外に、Cloudサービス(AWS)や 音楽や映画のストリーミングサービスも行ってる。 アプリケーション → amazouの基幹システム 届けたい価値 → amazouのビジネスの管理 ユーザ管理、商品管理、発注管理などなど (おもんなー)
27. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 27 ITエンジニア Amazou 基幹システム
28. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 28 DDDって、マジになんなん？ ドメインとは、アプリケーションが解決したい現実の領域のこと → アプリケーションを作る目的の『対象』 → amazouシステムを作る目的は『amazouのビジネスを管理する』 → amazouのドメインは『amazouのビジネス』 また、このドメインに詳しい人のことをドメインエキスパートと呼びます → amazouのビジネスに詳しいキーマンや、現場の人 amazouのドメインとは・・・
29. エンジニアがやるモデリングとは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 29 DDDって、マジになんなん？ amazouの複雑なビジネスの情報からエンジニアが扱いたい情報 だけを取り出しモデルを作成することです。 amazouビジネスの 要求・知識・ルール (DDD) ビジネス ドメインモデル 内容 例 要求 ビジネスとして『何を達成したいか』 新規注文時、お礼をする 知識 ビジネスの中で『どのように動いているか』 業務フロー・概念 ルール ビジネス上の制約 ユーザIDは一意 在庫が無い場合は発注できない
30. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 30 DDDって、マジになんなん？ ビジネス (ドメイン) ビジネスの要求、知識、ルール を表現したドメインモデル コード
31. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 31 DDDって、マジになんなん？ 新しいビジネスや 利益を最大化させれるような ビジネスのやり方ばかり考えている 美しいアーキテクチャや コーディングで表現できない かばかり考えてる ビジネス ドメインエキスパート エンジニア
32. どーして得意なの？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 32 DDDって、マジになんなん？ 視点 OOAD DDD フォーカス ドメイン(ビジネス)の情報の構造 ドメイン(ビジネス)の内容 要求・知識・ルール だれが作る？ エンジニア エンジニア + ドメインエキスパート 設計シナリオ ビジネスの内容を、 ドメインエキスパートからヒアリングし、 情報の構造モデルに再設計する ビジネスの内容を、 ドメインエキスパートと共に、 ビジネスのやり方のままモデル設計する ビジネスに変 更が起きた時 変更されたビジネスの内容を、 再度ドメインエキスパートからヒアリングし、 変更場所を探し出し変更を行う。 ビジネスの内容と異なる形でモデリングされているため、 影響範囲も別途調査する必要がある。 変更されたビジネスの内容と 同じものがモデルとしてあるので、 そのまま変更を行う。 ビジネスの内容のままモデリングされて いるため、ビジネスに影響が出る部分だ けに限定できる。
33. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 33 ITエンジニア Amazou 基幹システム ビジネスのやり方を構造 に変換させる
34. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 34 Amazou 基幹システム ドメインモデル ドメイン ただただドメインの 内容を反映させる
35. ドメインモデル作るぜ！！ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 35 DDDって、マジになんなん？ 名前 内容 例 ドメイン 現実世界の事業領域 amazouのビジネス サブドメイン 現実世界の業務領域(業務が連携されて事業が成り立つ) サブドメインには ・コアサブドメイン：競争優位性がある業務 ・支援サブドメイン：競争優位性はないが必要な業務 ・汎用サブドメイン：ごくごくありふれた一般的な業務 販売業務、在庫管理業 務、発送業務 境界付けられた コンテキスト サブドメインを情報の意味合いが同じもので分けて整理し たもの (販売業務の中には) 注文管理、顧客情報管 理 腐敗防止層 境界付けられたコンテキスト(ドメインモデル)の独立性を 担保するためのレイヤー ユビキタス言語 ドメインエキスパートも含め、必ず同じ言葉を使おうとい うルール ドメインモデル サブドメインをモデリングしたもの
36. 境界付けられたコンテキスト (注文管理) よくわからんので図解 y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 36 DDDの概要 ドメイン(amazouのビジネス) 問題空間(戦術設計) 解決空間(戦略設計) サブドメイン (販売業務) サブドメイン (在庫管理業務) ユビキタス 言語 ドメイン モデル 境界付けられた ユビキタス 言語 ドメイン モデル 腐敗防止層 境界付けられたコンテキスト ユビキタス 言語 ドメイン モデル ドメイン モデル ドメイン モデル 腐敗防止層 ドメイン モデル ソフトウェアアーキテクチャ
37. DDDの思想 y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 37 DDDって、マジになんなん？ ドメイン(ビジネス) をドメインエキスパートと共に理解し、 理解によって得られた知識(ビジネスの内容)や要求、ルールを 元にドメインモデル（ビジネスと同一のモデル）を作り、常に コードとドメイン(ビジネス)一体化させ続ける。 ドメイン(ビジネス) ドメインモデル コード
38. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 38 ドメインモデリング ドメインモデルとアプリケーションレイヤーの考え方 ドメイン モデル アプリケーション 新規注文時、お礼をする 注文をする お礼のメール お礼のチャット カートシステム サービス カートシステム OCR サービス メール送信 サービス チャット サービス 注文入力画面
39. ドメインモデルの実装 ぽいことをして、雰囲気を・・・ 02 y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 39
40. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 40 さーアンチパターンだ！
41. なぜ モデルだけ 作るのはアンチパターンなの？ 41 ドメインモデリング DDD はドメインを理解することがスタート地点。 なのに、いきなりモデルだけ作ると・・・ ・ビジネスの意図が入っていない ・ドメインエキスパートとのズレが広がる ・変更が入ると全部やり直しになる → DDDの本質『ドメイン中心』から外れるためアンチパターンといわれる → 個人的には別に良いんじゃー と思う・・・ というわけで今回のコード例は DDDの雰囲気を楽しむためのコード例です！！
42. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 42 ドメインモデルを実装してみよー ドメインルール編
43. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 43 ユーザIDの入力値の例は”UID-202511001”(識別子 - 年月 連番) 入力件数が多いため発注希望日は”20251117”のようにテンキーだけで入れれるようにしたい。 発注希望日はバリデーションも不要で日付の加減算もない。 また、表示も”20251117”のように数字のみで行う。 レイヤードアーキテクチャ(3階層アーキテクチャ)の場合、各レイヤーではどのようなデータ型で処 理しますか？ 最も最適な設計をするとしたらどうしますー？ アンケート！！ 項目名 プレゼンテーション ビジネスロジック データストア(DB) ユーザID データ型は何型？ 発送希望日
44. Date型って？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 44 ドメインモデリング 2025/11/17 19:00:00 10進数 12進数 月が 1,3,5,7,8,10,12の場合：31進数 4,6,9,11の場合：30進数 2の場合は、年が4で割り切れる場合は29 例外的に、100で割り切れる場合は、28 さらに例外的に、400で割り切れる場合は、 やっぱり29進数 時間も似たような感じ・・・ 24進数だったり60進数だったり 日付は地球の公転の周期を基準とし、 時間は地球の自転の周期を基準とする。 (日付は、不定期にうるう秒を入れることで整合 を保っている、2035年で廃止) 大前提として、相対性理論により 同一の重力、速度が同じ場合にのみ同一性が担保される。 国ごとに、表現方法が異なる 日本： 2025/11/17 アメリカ： Nov. 17. 2025 ドイツ： 17. 11. 2025
45. Date型って？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 45 ドメインモデリング 20251117 って数値？
46. Date型って？ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 46 ドメインモデリング 20251117 って数値？ numberって数字なら入れても良いの？ 項目名 プレゼンテーション ビジネスロジック データストア(DB) ユーザID データ型は何型？ 発送希望日
47. ドメインモデルを実装してみよー y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 47 ドメインモデリング DDDはドメインをそのままモデルに落とす設計手法 その最初のステップがドメインが持ってる値と 正しく向き合う事
48. ユーザIDも``ただの文字列``じゃない y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 48 ドメインモデリング UID-202511001 ・1～3桁は識別子 ・4桁目はセパレータ ・5～10桁目は生成年月 ・最後は連番 これってstring？
49. ユーザIDのドメインルール・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 49 ドメインモデリング ユーザIDはただのstringではない ・1～3桁は``UID``という識別子 ・4桁目はセパレータ ・5～10桁目は生成年月 ・最後は連番 → stringで殴った瞬間に、この意味が全部消える。
50. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 50 そんなあなたに朗報 バリューオブジェクト
51. バリューオブジェクトとは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 51 ドメインモデリング バリューオブジェクト(VO)は``意味のある値``の箱 VOの責務 ・不正な値は作らせない ・同じ値なら、同じものとして扱える ・値が変わらない(不変性：イミュータブル) ・意味のある操作(例：ユーザIDから登録月を抜き出す)を持てる → ``値の正しさ`` や 値固有の仕様をVOに任せることで、 システム全体の再利用性、安全性が爆上がり！ 例)ユーザID、発送希望日、名前、電話番号、数量
52. バリューオブジェクトとは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 52 ドメインモデリング [ユーザID] ├ validate() ├ getValue() └ 値に関するロジック JSのDate型の考えとほぼ一緒 異なるのは、値が変更できない事だけ
53. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 53 class UserId { private readonly value: string; constructor(value: string) { if (!this.validate(value)) { throw new Error("あかんユーザIDじゃない"); } this.value = value; } getValue(): string { return this.value; } getRegisterDate(): string { return this.value.slice(4, 10); } private validate(value: string): boolean { //1～3桁は `UID `という識別子 //4桁目はセパレータ //5～10桁目は生成年月 //最後は連番 return true } } const userId = new UserId("UID-202511001"); console.log(userId.getValue()); //UID-202511001 console.log(userId.getRegisterDate()); //202511 const userId = new UserId("ゆるテク"); //例外 VOの最大のメリットは、作られた 瞬間に、ドメイン的に仕様を満たし た値しかコード内に流れないところ 途中で不正な値に入れ替えたりする ことが絶対にできない。 また値固有のロジックもここにカプ セル化できる
54. ドメインモデルを実装してみよー y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 54 ドメインモデリング 発送情報って・・・ これって値？？ ユーザIDと日付をくっつけたVOを 作る？？？
55. ドメインモデルを実装してみよー y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 55 ドメインモデリング 値だけでは表現できない存在(ユーザ、発送情報)があ る。その存在は状態を持ち、固有のルールがある。 そんな時はエンティティ！
56. エンティティとは・・・ 56 ドメインモデリング エンティティ(ET)とは``存在（人・物・事柄）を表すモデル`` ETの責務 ・IDにより``同一性``を区別 ・状態(State)を持つ ・ドメインルール・ドメインロジックを持つ ・VOの組みまわせでできている → ``存在の正しさ`` や ``状態の正しさ``をエンティティに 集中させることができる！ 例)ユーザ、顧客、商品、在庫
57. エンティティとは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 57 ドメインモデリング [発送情報] ├ id : 発送ID(VO) ├ userid : ユーザID(VO) ├ shippingDete : 日付(VO) └ エンティティに関するロジック 普通のクラスと似たようなもん
58. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 58 各属性の整合性はVO側で行うため、 エンティティ側は発送情報固有のルー ルのみチェックを行う(すっきり!! またエンティティ固有のロジックもこ こにカプセル化できる class ShippingInfo { private id: ShippingId private uid: UserId private sDate: Date //DateというVO constructor(id: ShipingId, uid: UserId, sDate: Date) { if (sDate.getValue() <= 今日+1w) { throw new Error("発送は1w以降からやで"); } this.id = id; this.uid = uid; this.sDate = sDate; } getId(): ShippingId { return this.id; } getUserId(): UserId { return this.uid; } getShippingDate(): Date {return this.sDate; } //発送日の修正 updShippingDate(newValue: Date): void { this.sDate = newValue; } //発送日過ぎてる？ isDelayed(): boolean { return sDate.getValue() < 今日 } }
59. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 59 エンティティも作られた瞬間に、ドメイン的に仕様を 満たした存在しかコード内に流れない VO固有のチェックはVO生成時にVO側で行う try { const sInfo = new ShippingInfo(new ShippingId("SID-2025001"), new UserId("UID-2025001"), new Date(“2025/12/01”)) console.log(sInfo.getShippingDate().getValue()) //2025/12/01 console.log(sInfo.isDelayed()) //false } catch(e) { console.log(e) }
60. ドメインモデルを実装してみよー y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 60 ドメインモデリング 急にユーザIDの話に戻ります。
61. ユーザIDのドメインルールはまだある!! y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 61 ドメインモデリング UID-202511001 ・1～3桁は識別子 ・4桁目はセパレータ ・5～10桁目は生成年月 ・最後は連番
62. ユーザIDのドメインルールはまだある!! y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 62 ドメインモデリング たぶん…ユーザIDって複数集めたときだけ、 一意じゃないとダメとか言い出しますよね？ これってUserId(VO)の配列？ UID-20251102 UID-20251103 UID-20251101
63. ユーザIDのドメインルールはまだある!! y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 63 ドメインモデリング ユーザIDはただのstringではない ・1～3桁は``UID``という識別子 ・4桁目はセパレータ ・5～10桁目は生成年月 ・最後は連番 ・複数集まったら、一意でないとダメ → stringで殴った瞬間に、この意味が全部消える。 → UserID(VO)[]で殴った瞬間に 一意性をシステム中で意識し続ける必要がある
64. ここで問題勃発!! y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 64 ドメインモデリング ・VOはあくまでも値に閉じた責務を担当するので、 外部のVOとの関係性チェックは責務外 ・じゃ UserIds っていうエンティティを作る？ → それってビジネス的に本当に存在する概念ですか？ → そんなものドメインエキスパートの人言ってました？ また、情報構造の視点でモデル作ってません？ ・えっ？ならUserIDの一意性のチェックはドメインではなく システム要件になる？データIDの一意性ってコンピュータ的でしょ?? そーでしょ？ そーでしょ？ そーだと思ったんだー → IDが一意ってビジネス的な制約なのでドメインルールです
65. ここで問題勃発!! y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 65 ドメインモデリング じゃー どーすんだよー
66. ドメインモデルを実装してみよー y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 66 ドメインモデリング 値でも実体でもないだけどちゃんとしたドメインルール があった場合どうするの？ そんなお悩みには``ドメインサービス``
67. ドメインサービスとは・・・ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 67 ドメインモデリング 値でもエンティティでもないドメインルールの置き場 ドメインサービスって ・VOにもエンティティの責務を超えている ・複数のVOやエンティティにまたがる ・でも、ドメインルールそのもの 基本ステートレス(状態を持たない、ロジックだけ) 例) ユーザ登録サービス、送料計算サービス
68. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 68 class UserRegistrationService { register( user: User; ) { // --- ドメインルール：UserId の重複不可 --- const existing = userRepository.findById(user.getId()); if (existing) { throw new Error(“UserIdはすでに存在しとる"); } userRepository.save(user); } } const user = new User(new UserId("UID-2025001"), new Age(21)) registrationService.register(user); // 成功 const user2 = new User(new UserId("UID-2025001"), new Age(21)) registrationService.register(user); // Idが同じため例外
69. ドメインモデルのまとめ y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 69 ドメインモデリング 名前 なにを表す？ ルール 状態 例 バリューオブジェクト 意味のある値 値の正しさ × ユーザID、 発送希望日 名前 電話番号 数量 エンティティ 実体(人・物・事柄) 存在の正しさ 〇 ユーザ 商品 在庫 ドメインサービス VOにもエンティティに も属しないルール VOやエンティティに またがるロジック × ユーザ登録サービス 送料計算サービス 集約 ホントはこれが一番大事w ドメイン単位のまとまり 一貫性の正しさ 〇 発注業務 (ユーザ + 商品 + 在庫)
70. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 70 ドメインモデリング ドメインモデルとアプリケーションレイヤーの考え方 ドメイン モデル アプリケーション 新規注文時、お礼をする 注文をする お礼のメール お礼のチャット カートシステム サービス カートシステム OCR サービス メール送信 サービス チャット サービス 注文入力画面
71. まとめ 03 y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 71
72. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 72 DDDは、ドメインをドメインエキスパートと共に理解し、 理解によって得られた要求、知識、ルールを視点にドメインモ デルを作り、常にコードとドメイン一体化させ続けることによ り、変更容易性の高いシステムを作り上げる設計手法。 ドメイン(ビジネス) ドメインモデル コード
73. y u r u t e c h n a n k a s o r e p p o i b e n k y o k a i 2 0 2 5 . 1 1 73 ドメインを神と仰ぎ、開発の中心に置くとすべてがうまく行く!! しらんけど