Slide 1
Slide 1 text
アンチパターンと言われようとも、
何となく楽しいところだけするDDD
株式会社MICHIRU おーのりょう
ゆ る テ ク な ん か そ れ っ ぽ い 勉 強 会 2 0 2 5 . 1 1 2 0 2 5 - 1 1 - 1 7
Slide 2
Slide 2 text
会社： 株式会社MICHIRU / zeit
自己紹介
マイルール： 正しさよりも、楽しさを
おーの りょう
2
Slide 3
Slide 3 text
3
最近、うれしいこと：
上の部屋のお母さんが、ちょっと良い洗濯ばさみを、
ちょいちょい落としてくる。
Slide 4
Slide 4 text
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
今日ですが・・・
資料の出来が過去一悪いです・・・
Slide 5
Slide 5 text
催眠商法で学ぶ
アンチパターンと言われようとも、
何となく楽しいところだけするDDD
株式会社MICHIRU おーのりょう
ゆ る テ ク な ん か そ れ っ ぽ い 勉 強 会 2 0 2 5 . 1 1 2 0 2 5 - 1 1 - 1 7
Slide 6
Slide 6 text
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の思想と雰囲気がなんとなくわかる
今日のゴール
まーアレですよ・・・ 内容がひどい言い訳ですよ。
Slide 7
Slide 7 text
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 千利休
まずはアーキテクチャや技術を理解し身につける、
その後は自分や環境に合わせてより良い形に変える。
最後は本質を忘れずに、自分なりの新しいやり方を模索
する。
Slide 8
Slide 8 text
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
Slide 9
Slide 9 text
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
うんっ! よくわからん!
Slide 10
Slide 10 text
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エンジニアの仕事の本質』から入ると、
理解しやすいかも。
しらんけど
Slide 11
Slide 11 text
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って、マジになんなん？
仕事：価値を生み出すこと
・世の中の課題を解決させるアイデアを考えた。
・世の中を変えてしまうような文化や体験を創り出した。
Slide 12
Slide 12 text
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って、マジになんなん？
仕事：価値を生み出すこと
・世の中の課題を解決させるアイデアを考えた。
・世の中を変えてしまうような文化や体験を創り出した。
作業：価値は生み出さないけど、やらないといけないこと
・マネジメント
・プログラミング
・テスト
Slide 13
Slide 13 text
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って、マジになんなん？
じゃ、俺たちがやらなければならないことはなんだ！！
Slide 14
Slide 14 text
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
エンジニアリング / アート
Slide 15
Slide 15 text
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）
世の中(現実)
世界は日々変化し
続けている
Slide 16
Slide 16 text
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って、マジになんなん？
世の中の情報(社会課題、ビジネス)を解釈し続け、
そこから価値を創造し表現して世界に届け続けること。
Slide 17
Slide 17 text
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デス
Slide 18
Slide 18 text
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
どーして得意なの？
Slide 19
Slide 19 text
どーして得意なの？
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は現実世界がそのままコードに落ちているため
“お前どこ直せば良いんだよ”問題が起きずらい。
(変更容易性が高いシステムになる)
Slide 20
Slide 20 text
どーして得意なの？
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
Slide 21
Slide 21 text
どーして得意なの？
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って、マジになんなん？
具体的にはドメインを要求、知識、ルールという視点でモデリ
ングしたドメインモデルを作成し、このモデルとコードを合わ
せることにより、現実世界をそのままのコード化させる。
世の中(ドメイン)
世の中の要求、知識、ルール
をまとめたドメインモデル
コード
Slide 22
Slide 22 text
どーして得意なの？
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って、マジになんなん？
ドメインとは、アプリケーションが解決したい現実の領域のこと
→ アプリケーションを作る目的の『対象』
また、このドメインに詳しい人のことをドメインエキスパートと呼びます
→ 世の中に詳しい人 (神様？？)
ドメインとは・・・
Slide 23
Slide 23 text
どーして得意なの？
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って、マジになんなん？
モデルとは・・・
分かり辛く扱いにくいものを意識したい情報に絞ることにより、
扱いやすくしたもの
地球
面積、場所
地球儀
ジオイド
重力の強さ
Slide 24
Slide 24 text
エンジニアがやるモデリングとは・・・
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)
概念モデル
ドメインモデル
ドメイン(世の中)
Slide 25
Slide 25 text
どーして得意なの？
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って、マジになんなん？
世の中、世の中って連呼されても頭に入らない・・・
Slide 26
Slide 26 text
どーして得意なの？
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のビジネスの管理
ユーザ管理、商品管理、発注管理などなど (おもんなー)
Slide 27
Slide 27 text
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
基幹システム
Slide 28
Slide 28 text
どーして得意なの？
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のドメインとは・・・
Slide 29
Slide 29 text
エンジニアがやるモデリングとは・・・
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は一意
在庫が無い場合は発注できない
Slide 30
Slide 30 text
どーして得意なの？
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って、マジになんなん？
ビジネス (ドメイン)
ビジネスの要求、知識、ルール
を表現したドメインモデル
コード
Slide 31
Slide 31 text
どーして得意なの？
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って、マジになんなん？
新しいビジネスや
利益を最大化させれるような
ビジネスのやり方ばかり考えている
美しいアーキテクチャや
コーディングで表現できない
かばかり考えてる
ビジネス
ドメインエキスパート エンジニア
Slide 32
Slide 32 text
どーして得意なの？
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
フォーカス ドメイン(ビジネス)の情報の構造 ドメイン(ビジネス)の内容
要求・知識・ルール
だれが作る？ エンジニア エンジニア + ドメインエキスパート
設計シナリオ ビジネスの内容を、
ドメインエキスパートからヒアリングし、
情報の構造モデルに再設計する
ビジネスの内容を、
ドメインエキスパートと共に、
ビジネスのやり方のままモデル設計する
ビジネスに変
更が起きた時
変更されたビジネスの内容を、
再度ドメインエキスパートからヒアリングし、
変更場所を探し出し変更を行う。
ビジネスの内容と異なる形でモデリングされているため、
影響範囲も別途調査する必要がある。
変更されたビジネスの内容と
同じものがモデルとしてあるので、
そのまま変更を行う。
ビジネスの内容のままモデリングされて
いるため、ビジネスに影響が出る部分だ
けに限定できる。
Slide 33
Slide 33 text
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
基幹システム
ビジネスのやり方を構造
に変換させる
Slide 34
Slide 34 text
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
基幹システム
ドメインモデル
ドメイン
ただただドメインの
内容を反映させる
Slide 35
Slide 35 text
ドメインモデル作るぜ！！
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のビジネス
サブドメイン
現実世界の業務領域(業務が連携されて事業が成り立つ)
サブドメインには
・コアサブドメイン：競争優位性がある業務
・支援サブドメイン：競争優位性はないが必要な業務
・汎用サブドメイン：ごくごくありふれた一般的な業務
販売業務、在庫管理業
務、発送業務
境界付けられた
コンテキスト
サブドメインを情報の意味合いが同じもので分けて整理し
たもの
(販売業務の中には)
注文管理、顧客情報管
理
腐敗防止層
境界付けられたコンテキスト(ドメインモデル)の独立性を
担保するためのレイヤー
ユビキタス言語
ドメインエキスパートも含め、必ず同じ言葉を使おうとい
うルール
ドメインモデル サブドメインをモデリングしたもの
Slide 36
Slide 36 text
境界付けられたコンテキスト
(注文管理)
よくわからんので図解
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のビジネス)
問題空間(戦術設計) 解決空間(戦略設計)
サブドメイン
(販売業務)
サブドメイン
(在庫管理業務)
ユビキタス
言語
ドメイン
モデル
境界付けられた
ユビキタス
言語
ドメイン
モデル
腐敗防止層
境界付けられたコンテキスト
ユビキタス
言語
ドメイン
モデル
ドメイン
モデル
ドメイン
モデル
腐敗防止層
ドメイン
モデル
ソフトウェアアーキテクチャ
Slide 37
Slide 37 text
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って、マジになんなん？
ドメイン(ビジネス) をドメインエキスパートと共に理解し、
理解によって得られた知識(ビジネスの内容)や要求、ルールを
元にドメインモデル（ビジネスと同一のモデル）を作り、常に
コードとドメイン(ビジネス)一体化させ続ける。
ドメイン(ビジネス) ドメインモデル コード
Slide 38
Slide 38 text
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
サービス
メール送信
サービス
チャット
サービス
注文入力画面
Slide 39
Slide 39 text
ドメインモデルの実装
ぽいことをして、雰囲気を・・・
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
Slide 40
Slide 40 text
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
さーアンチパターンだ！
Slide 41
Slide 41 text
なぜ モデルだけ 作るのはアンチパターンなの？
41
ドメインモデリング
DDD はドメインを理解することがスタート地点。
なのに、いきなりモデルだけ作ると・・・
・ビジネスの意図が入っていない
・ドメインエキスパートとのズレが広がる
・変更が入ると全部やり直しになる
→ DDDの本質『ドメイン中心』から外れるためアンチパターンといわれる
→ 個人的には別に良いんじゃー と思う・・・
というわけで今回のコード例は
DDDの雰囲気を楽しむためのコード例です！！
Slide 42
Slide 42 text
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
ドメインモデルを実装してみよー
ドメインルール編
Slide 43
Slide 43 text
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 データ型は何型？
発送希望日
Slide 44
Slide 44 text
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
Slide 45
Slide 45 text
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 って数値？
Slide 46
Slide 46 text
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 データ型は何型？
発送希望日
Slide 47
Slide 47 text
ドメインモデルを実装してみよー
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はドメインをそのままモデルに落とす設計手法
その最初のステップがドメインが持ってる値と
正しく向き合う事
Slide 48
Slide 48 text
ユーザ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？
Slide 49
Slide 49 text
ユーザ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で殴った瞬間に、この意味が全部消える。
Slide 50
Slide 50 text
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
そんなあなたに朗報
バリューオブジェクト
Slide 51
Slide 51 text
バリューオブジェクトとは・・・
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、発送希望日、名前、電話番号、数量
Slide 52
Slide 52 text
バリューオブジェクトとは・・・
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型の考えとほぼ一緒
異なるのは、値が変更できない事だけ
Slide 53
Slide 53 text
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の最大のメリットは、作られた
瞬間に、ドメイン的に仕様を満たし
た値しかコード内に流れないところ
途中で不正な値に入れ替えたりする
ことが絶対にできない。
また値固有のロジックもここにカプ
セル化できる
Slide 54
Slide 54 text
ドメインモデルを実装してみよー
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を
作る？？？
Slide 55
Slide 55 text
ドメインモデルを実装してみよー
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
ドメインモデリング
値だけでは表現できない存在(ユーザ、発送情報)があ
る。その存在は状態を持ち、固有のルールがある。
そんな時はエンティティ！
Slide 56
Slide 56 text
エンティティとは・・・
56
ドメインモデリング
エンティティ(ET)とは``存在（人・物・事柄）を表すモデル``
ETの責務
・IDにより``同一性``を区別
・状態(State)を持つ
・ドメインルール・ドメインロジックを持つ
・VOの組みまわせでできている
→ ``存在の正しさ`` や ``状態の正しさ``をエンティティに
集中させることができる！
例)ユーザ、顧客、商品、在庫
Slide 57
Slide 57 text
エンティティとは・・・
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)
└ エンティティに関するロジック
普通のクラスと似たようなもん
Slide 58
Slide 58 text
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() < 今日
}
}
Slide 59
Slide 59 text
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)
}
Slide 60
Slide 60 text
ドメインモデルを実装してみよー
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の話に戻ります。
Slide 61
Slide 61 text
ユーザ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桁目は生成年月
・最後は連番
Slide 62
Slide 62 text
ユーザ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
Slide 63
Slide 63 text
ユーザ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)[]で殴った瞬間に
一意性をシステム中で意識し続ける必要がある
Slide 64
Slide 64 text
ここで問題勃発!!
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が一意ってビジネス的な制約なのでドメインルールです
Slide 65
Slide 65 text
ここで問題勃発!!
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
ドメインモデリング
じゃー どーすんだよー
Slide 66
Slide 66 text
ドメインモデルを実装してみよー
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
ドメインモデリング
値でも実体でもないだけどちゃんとしたドメインルール
があった場合どうするの？
そんなお悩みには``ドメインサービス``
Slide 67
Slide 67 text
ドメインサービスとは・・・
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やエンティティにまたがる
・でも、ドメインルールそのもの
基本ステートレス(状態を持たない、ロジックだけ)
例) ユーザ登録サービス、送料計算サービス
Slide 68
Slide 68 text
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が同じため例外
Slide 69
Slide 69 text
ドメインモデルのまとめ
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
ドメイン単位のまとまり 一貫性の正しさ 〇
発注業務
(ユーザ + 商品 + 在庫)
Slide 70
Slide 70 text
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
サービス
メール送信
サービス
チャット
サービス
注文入力画面
Slide 71
Slide 71 text
まとめ
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
Slide 72
Slide 72 text
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は、ドメインをドメインエキスパートと共に理解し、
理解によって得られた要求、知識、ルールを視点にドメインモ
デルを作り、常にコードとドメイン一体化させ続けることによ
り、変更容易性の高いシステムを作り上げる設計手法。
ドメイン(ビジネス) ドメインモデル コード
Slide 73
Slide 73 text
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
ドメインを神と仰ぎ、開発の中心に置くとすべてがうまく行く!!
しらんけど