クイズの説明
Step 4で学んだDDDの理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は復習してから再挑戦してください
問題
Q1. ユビキタス言語（Ubiquitous Language）の説明として正しいものはどれですか？
- A) プログラミング言語を統一すること
- B) 開発者とドメインエキスパートが共通で使うビジネスの言葉
- C) 英語でコードを書くこと
- D) APIの命名規則を統一すること
答えを見る
正解: B
ユビキタス言語は、開発者とドメインエキスパート（業務担当者）が共通で使う言葉です。「出荷停止」と「キャンセル」のような業務上の区別がコードにもそのまま反映されます。言葉のズレがバグの原因になるため、チーム全体で統一した言葉を使うことが重要です。
Q2. ECサイトにおいて「商品」がBounded Contextごとに異なるモデルを持つ理由はどれですか？
- A) データベースのパフォーマンスを最適化するため
- B) 各コンテキストで商品に対する関心事（表示情報、注文金額、在庫数）が異なるため
- C) プログラミング言語が異なるため
- D) セキュリティ上の理由
答えを見る
正解: B
カタログBCでは商品の表示情報（名前、説明、画像）が重要で、注文BCでは注文時の確定金額が重要で、在庫BCでは物理的な在庫数とロケーションが重要です。同じ「商品」でもコンテキストによって関心事が異なるため、それぞれ最適なモデルを持つべきです。
Q3. Aggregate（集約）のルールとして誤っているものはどれですか？
- A) 外部からはAggregate Rootのメソッドを通じてのみ操作する
- B) 1つのトランザクションで複数のAggregateを同時に更新してよい
- C) Aggregate間はIDでのみ参照する
- D) Aggregateは必要最小限のEntityを含める
答えを見る
正解: B
1つのトランザクションでは1つのAggregateのみ更新するのが原則です。複数のAggregateを同時に更新すると、トランザクションのスコープが大きくなり、パフォーマンスの問題や並行制御の問題が発生します。複数のAggregate間の整合性は、ドメインイベントを使って結果整合性（eventual consistency）で保ちます。
Q4. ドメインイベントの命名規則として正しいものはどれですか？
- A) 命令形で命名する（例: CreateOrder）
- B) 過去形で命名する（例: OrderCreated）
- C) 現在形で命名する（例: OrderCreating）
- D) 名詞で命名する（例: Order）
答えを見る
正解: B
ドメインイベントは「過去に起きた事実」を表現するため、過去形で命名します。OrderCreated（注文が作成された）、PaymentCompleted（決済が完了した）のように、すでに発生した出来事であることを名前で示します。命令形（CreateOrder）はコマンドの命名規則です。
Q5. Anti-Corruption Layer（ACL）の役割として正しいものはどれですか？
- A) セキュリティ攻撃を防御する
- B) 外部システムのモデルが自分のドメインモデルを汚染しないように変換層を設ける
- C) データベースのバックアップを取る
- D) コードの品質を自動チェックする
答えを見る
正解: B
Anti-Corruption Layer（腐敗防止層）は、外部システムのモデル（API仕様、データ形式等）が自分のBounded Contextのドメインモデルに侵入しないようにする変換層です。外部APIのrecipient（受取人）を自分のドメインのShippingAddress（配送先）に変換するなど、外部の言葉を自分のドメインの言葉に翻訳します。
Q6. EntityとValue Objectの使い分けとして正しいものはどれですか？
- A) 大きなオブジェクトはEntity、小さなオブジェクトはValue Object
- B) 同一性（ID）で識別するものはEntity、値で識別するものはValue Object
- C) データベースに保存するものはEntity、保存しないものはValue Object
- D) メソッドを持つものはEntity、持たないものはValue Object
答えを見る
正解: B
EntityはID（同一性）で識別します。注文のステータスが変わっても同じ注文です。Value Objectは値そのもので識別します。Money(1000, ‘JPY’)とMoney(1000, ‘JPY’)は等しいです。Value Objectも自己検証や計算のメソッドを持ちます。サイズやDB保存の有無は判断基準ではありません。
Q7. イベントストーミングの正しい手順はどれですか？
- A) アクター → コマンド → イベント → Aggregate → BC
- B) BC → Aggregate → イベント → コマンド → アクター
- C) イベント → コマンド → アクター → Aggregate → BC
- D) Aggregate → イベント → BC → コマンド → アクター
答えを見る
正解: C
イベントストーミングは、まずドメインイベント（何が起きたか）を洗い出し、次にそのイベントを発生させるコマンド（何をするか）を特定し、コマンドを実行するアクター（誰がするか）を特定します。その後、イベントとコマンドをグルーピングしてAggregate（集約）を発見し、最終的にBounded Contextの境界を決定します。
Q8. 以下のコードでDDDの原則に違反している箇所はどこですか？
class Order {
items: OrderItem[]; // (1) publicフィールド
status: string; // (2) 文字列のステータス
addItem(item: OrderItem): void {
this.items.push(item); // (3) バリデーションなし
}
}
// 外部から直接操作
order.items[0].quantity = 100; // (4) Aggregate Root経由でない- A) (1)と(2)のみ
- B) (1)と(3)と(4)
- C) (1)と(2)と(3)と(4)
- D) (4)のみ
答えを見る
正解: C
(1) フィールドがpublicだと外部から直接変更でき、不変条件が保護されません。privateにすべきです。(2) ステータスが文字列だと不正な値が入る可能性があります。Enumまたは専用のValue Objectにすべきです。(3) 商品追加時にビジネスルール（最大数量チェック、ステータスチェック等）のバリデーションがありません。(4) Aggregate内のEntityを外部から直接操作しており、Aggregate Rootを経由するルールに違反しています。
結果
7問以上正解の場合
合格です。おめでとうございます。
Step 4「ドメイン駆動設計（DDD）」を完了しました。 次は Step 5「アーキテクチャの実践と評価」に進みましょう。
6問以下の場合
もう少し復習しましょう。
| 問題 | 復習セクション |
|---|---|
| Q1, Q2 | step4_1 DDDの戦略的設計 |
| Q3, Q6 | step4_2 DDDの戦術的設計 |
| Q4 | step4_3 ドメインイベントとイベントストーミング |
| Q5 | step4_4 コンテキストマップとチーム境界 |
| Q7 | step4_3 イベントストーミング |
| Q8 | step4_2 Aggregate |
Step 4 完了
お疲れさまでした。
学んだこと
- 戦略的設計: Ubiquitous Language, Bounded Context
- 戦術的設計: Entity, Value Object, Aggregate, Domain Service
- ドメインイベントの設計と発行
- イベントストーミングによるドメイン発見
- コンテキストマップと6つの関係パターン
次のステップ
Step 5: アーキテクチャの実践と評価（4時間）
学んだアーキテクチャをどう評価し、トレードオフをどう判断するかを学びます。
推定所要時間: 30分