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 千利休 まずはアーキテクチャや技術を理解し身につける、 その後は自分や環境に合わせてより良い形に変える。 最後は本質を忘れずに、自分なりの新しいやり方を模索 する。
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 うんっ! よくわからん!
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って、マジになんなん？ 仕事：価値を生み出すこと ・世の中の課題を解決させるアイデアを考えた。 ・世の中を変えてしまうような文化や体験を創り出した。 作業：価値は生み出さないけど、やらないといけないこと ・マネジメント ・プログラミング ・テスト
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 エンジニアリング / アート
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は現実世界がそのままコードに落ちているため “お前どこ直せば良いんだよ”問題が起きずらい。 (変更容易性が高いシステムになる)
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
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って、マジになんなん？ 具体的にはドメインを要求、知識、ルールという視点でモデリ ングしたドメインモデルを作成し、このモデルとコードを合わ せることにより、現実世界をそのままのコード化させる。 世の中(ドメイン) 世の中の要求、知識、ルール をまとめたドメインモデル コード
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って、マジになんなん？ ドメインとは、アプリケーションが解決したい現実の領域のこと → アプリケーションを作る目的の『対象』 また、このドメインに詳しい人のことをドメインエキスパートと呼びます → 世の中に詳しい人 (神様？？) ドメインとは・・・
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) 概念モデル ドメインモデル ドメイン(世の中)
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のビジネスの管理 ユーザ管理、商品管理、発注管理などなど (おもんなー)
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のドメインとは・・・
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は一意 在庫が無い場合は発注できない
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って、マジになんなん？ 新しいビジネスや 利益を最大化させれるような ビジネスのやり方ばかり考えている 美しいアーキテクチャや コーディングで表現できない かばかり考えてる ビジネス ドメインエキスパート エンジニア
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 フォーカス ドメイン(ビジネス)の情報の構造 ドメイン(ビジネス)の内容 要求・知識・ルール だれが作る？ エンジニア エンジニア + ドメインエキスパート 設計シナリオ ビジネスの内容を、 ドメインエキスパートからヒアリングし、 情報の構造モデルに再設計する ビジネスの内容を、 ドメインエキスパートと共に、 ビジネスのやり方のままモデル設計する ビジネスに変 更が起きた時 変更されたビジネスの内容を、 再度ドメインエキスパートからヒアリングし、 変更場所を探し出し変更を行う。 ビジネスの内容と異なる形でモデリングされているため、 影響範囲も別途調査する必要がある。 変更されたビジネスの内容と 同じものがモデルとしてあるので、 そのまま変更を行う。 ビジネスの内容のままモデリングされて いるため、ビジネスに影響が出る部分だ けに限定できる。
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のビジネス サブドメイン 現実世界の業務領域(業務が連携されて事業が成り立つ) サブドメインには ・コアサブドメイン：競争優位性がある業務 ・支援サブドメイン：競争優位性はないが必要な業務 ・汎用サブドメイン：ごくごくありふれた一般的な業務 販売業務、在庫管理業 務、発送業務 境界付けられた コンテキスト サブドメインを情報の意味合いが同じもので分けて整理し たもの (販売業務の中には) 注文管理、顧客情報管 理 腐敗防止層 境界付けられたコンテキスト(ドメインモデル)の独立性を 担保するためのレイヤー ユビキタス言語 ドメインエキスパートも含め、必ず同じ言葉を使おうとい うルール ドメインモデル サブドメインをモデリングしたもの
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のビジネス) 問題空間(戦術設計) 解決空間(戦略設計) サブドメイン (販売業務) サブドメイン (在庫管理業務) ユビキタス 言語 ドメイン モデル 境界付けられた ユビキタス 言語 ドメイン モデル 腐敗防止層 境界付けられたコンテキスト ユビキタス 言語 ドメイン モデル ドメイン モデル ドメイン モデル 腐敗防止層 ドメイン モデル ソフトウェアアーキテクチャ
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って、マジになんなん？ ドメイン(ビジネス) をドメインエキスパートと共に理解し、 理解によって得られた知識(ビジネスの内容)や要求、ルールを 元にドメインモデル（ビジネスと同一のモデル）を作り、常に コードとドメイン(ビジネス)一体化させ続ける。 ドメイン(ビジネス) ドメインモデル コード
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 サービス メール送信 サービス チャット サービス 注文入力画面
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 データ型は何型？ 発送希望日
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
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 データ型は何型？ 発送希望日
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で殴った瞬間に、この意味が全部消える。
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、発送希望日、名前、電話番号、数量
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の最大のメリットは、作られた 瞬間に、ドメイン的に仕様を満たし た値しかコード内に流れないところ 途中で不正な値に入れ替えたりする ことが絶対にできない。 また値固有のロジックもここにカプ セル化できる
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) └ エンティティに関するロジック 普通のクラスと似たようなもん
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() < 今日 } }
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) }
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
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)[]で殴った瞬間に 一意性をシステム中で意識し続ける必要がある
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が一意ってビジネス的な制約なのでドメインルールです
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やエンティティにまたがる ・でも、ドメインルールそのもの 基本ステートレス(状態を持たない、ロジックだけ) 例) ユーザ登録サービス、送料計算サービス
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が同じため例外
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 ドメイン単位のまとまり 一貫性の正しさ 〇 発注業務 (ユーザ + 商品 + 在庫)
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 サービス メール送信 サービス チャット サービス 注文入力画面
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は、ドメインをドメインエキスパートと共に理解し、 理解によって得られた要求、知識、ルールを視点にドメインモ デルを作り、常にコードとドメイン一体化させ続けることによ り、変更容易性の高いシステムを作り上げる設計手法。 ドメイン(ビジネス) ドメインモデル コード
SiteGround - Reliable hosting with speed, security, and support you can count on.
kajitack
koic
ochtum
matsuo_atsushi
naokihaba
blueswen
ternbusty
16bitidol
har1101
simotin13
musan
404background
uxyall
jnunemaker
axbom
bcantrill
akihiro_kokubo
mojombo
jmmastey
wjessup
honnibal
rocio
aki_iinuma
danielanewman
