クイズの説明
Step 3で学んだクリーンアーキテクチャの理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は復習してから再挑戦してください
問題
Q1. クリーンアーキテクチャの4層のうち、最も内側に位置する層はどれですか？
- A) Frameworks & Drivers
- B) Interface Adapters
- C) Application Business Rules
- D) Enterprise Business Rules（Entities）
答えを見る
正解: D
クリーンアーキテクチャの4層は、内側から順に Enterprise Business Rules（Entities）→ Application Business Rules（Use Cases）→ Interface Adapters → Frameworks & Drivers です。Enterprise Business Rules（エンティティ層）は最も安定したビジネスルールを含み、外部の変化に影響されません。
Q2. Use Caseの出力として適切なのはどれですか？
- A) Expressのレスポンスオブジェクト
- B) ドメインエンティティ（Order）をそのまま返す
- C) 専用のOutput型（DTO）を返す
- D) PrismaのQueryResultをそのまま返す
答えを見る
正解: C
Use Caseは専用のOutput型（DTO）を返すべきです。Expressのレスポンスオブジェクトを返すとフレームワークに依存し、ドメインエンティティをそのまま返すと内部構造が外側に露出します。PrismaのQueryResultはインフラ層の詳細です。専用のOutput型を使うことで、Use Caseがフレームワーク非依存かつドメイン非露出となります。
Q3. 依存性ルール（Dependency Rule）の説明として正しいものはどれですか？
- A) 外側の層は内側の層に依存する。内側の層は外側の層について何も知らない
- B) 内側の層は外側の層に依存する
- C) すべての層が相互に依存する
- D) 依存関係は存在しない
答えを見る
正解: A
クリーンアーキテクチャの依存性ルールは「ソースコードの依存は常に内側に向かう」というものです。内側の層（Entity, Use Case）は外側の層（Adapter, Framework）について一切知りません。外側の層が内側の層に依存します。これにより、内側の安定したビジネスロジックが外側の不安定な技術詳細に影響されません。
Q4. Composition Rootの役割として正しいものはどれですか？
- A) ドメインのビジネスルールを定義する
- B) 全ての依存関係を組み立てるアプリケーションのエントリーポイント
- C) データベースのマイグレーションを実行する
- D) テストのフレームワークを設定する
答えを見る
正解: B
Composition Rootは、全ての依存関係を組み立てる場所です。アプリケーションの起動時に1回だけ実行され、どのインターフェースにどの実装を注入するかを決定します。本番環境ではPrisma + Stripeなどの実装を、テスト環境ではInMemory + Stubの実装を注入します。
Q5. コンストラクタインジェクションが推奨される理由として最も適切なものはどれですか？
- A) コードの行数が少なくなるから
- B) 依存が明示的で、注入忘れがコンパイル時に検出されるから
- C) フレームワークが自動的に実行してくれるから
- D) テストが不要になるから
答えを見る
正解: B
コンストラクタインジェクションでは、必要な依存がコンストラクタのパラメータとして明示されます。依存を渡し忘れた場合、TypeScriptのコンパイル時にエラーが検出されます。セッターインジェクションでは注入忘れが実行時まで検出できず、予期しないnullエラーの原因になります。
Q6. テスト時にStubとSpyの使い分けとして正しいものはどれですか？
- A) StubもSpyも同じ目的で使う
- B) Stubは固定の戻り値を返す。Spyは呼び出しの記録・検証に使う
- C) Stubは本番環境で使い、Spyはテストで使う
- D) Stubはデータベースのモック、Spyは外部APIのモック
答えを見る
正解: B
Stubは「あらかじめ定義された固定の戻り値を返す」テストダブルです（例: StubPaymentGateway.setSuccess(true)）。Spyは「呼び出されたかどうか、何回呼ばれたか、どんな引数で呼ばれたか」を記録し検証するテストダブルです（例: SpyNotifier.wasCalled()）。
Q7. 以下のUse Caseコードの問題点はどれですか？
class CreateOrderUseCase {
async execute(req: express.Request): Promise<express.Response> {
const order = Order.create(req.body.customerId, req.body.items);
await prisma.order.create({ data: order.toPersistence() });
return res.json({ orderId: order.id.value });
}
}- A) Orderの生成方法が間違っている
- B) Use CaseがExpress（フレームワーク）とPrisma（ORM）に直接依存している
- C) 非同期処理の書き方が間違っている
- D) 戻り値の型が間違っている
答えを見る
正解: B
Use Case（Layer 2）はExpress（Layer 4）やPrisma（Layer 4）に直接依存してはいけません。依存性ルールに違反しています。入力は専用のInput型、出力は専用のOutput型を使い、データの永続化はOrderRepository（Port）を通じて行うべきです。
Q8. テストピラミッドにおいて、最も数が多くあるべきテストはどれですか？
- A) E2Eテスト
- B) 統合テスト
- C) ユニットテスト（Entity, Use Case）
- D) 負荷テスト
答えを見る
正解: C
テストピラミッドでは、底辺のユニットテストが最も多く、頂点のE2Eテストが最も少ないのが理想です。ユニットテストはEntity（純粋なビジネスロジック）やUse Case（InMemory依存）のテストで、高速に実行でき、フィードバックが即座に得られます。E2Eテストは実行が遅く、不安定になりやすいため、少数に限定します。
結果
7問以上正解の場合
合格です。おめでとうございます。
Step 3「クリーンアーキテクチャ」を完了しました。 次は Step 4「ドメイン駆動設計（DDD）」に進みましょう。
6問以下の場合
もう少し復習しましょう。
| 問題 | 復習セクション |
|---|---|
| Q1 | step3_1 クリーンアーキテクチャの4層構造 |
| Q2 | step3_2 Use Caseの設計 |
| Q3 | step3_1 依存性ルール |
| Q4 | step3_3 依存性注入（DI）の実践 |
| Q5 | step3_3 依存性注入（DI）の実践 |
| Q6 | step3_4 テスタビリティの確保 |
| Q7 | step3_1 / step3_2 4層構造とUse Case |
| Q8 | step3_4 テスタビリティの確保 |
Step 3 完了
お疲れさまでした。
学んだこと
- クリーンアーキテクチャの4層構造と依存性ルール
- Use Caseの設計（Input/Output、Command/Query）
- 依存性注入とComposition Root
- テスタビリティの確保（Stub, Spy, InMemory）
次のステップ
Step 4: ドメイン駆動設計（DDD）（5時間）
アーキテクチャの内側 — ドメインモデルをどう設計するかを深く学びます。Bounded Context、Entity、Value Object、Aggregateなどの概念を身につけましょう。
推定所要時間: 30分