クイズの説明
Step 1で学んだ内容の理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は復習してから再挑戦してください
問題
Q1. ソフトウェアアーキテクチャが解決する問題として最も適切なものはどれですか？
- A) 個々の関数のパフォーマンスを最適化する
- B) システム全体の構造を定義し、変更の影響範囲を限定する
- C) UIのデザインを美しくする
- D) データベースのクエリを高速化する
答えを見る
正解: B
アーキテクチャはシステム全体の構造と境界のルールを定めるものです。個々の関数やクエリの最適化はコードレベルの問題であり、アーキテクチャの主な関心事ではありません。アーキテクチャによって変更の影響範囲が限定され、テスト容易性やチーム分担が改善されます。
Q2. レイヤードアーキテクチャの「貧血ドメインモデル」とはどのような状態ですか？
- A) エンティティにビジネスロジックが集中しすぎている状態
- B) エンティティがデータの入れ物になり、ビジネスロジックがService層に分散する状態
- C) データベースのテーブル数が少なすぎる状態
- D) ドメインモデルのクラス数が多すぎる状態
答えを見る
正解: B
貧血ドメインモデル（Anemic Domain Model）とは、エンティティがプロパティ（データ）のみを持ち、メソッド（振る舞い）を持たない状態です。本来エンティティが持つべきビジネスロジックがService層に書かれてしまい、エンティティはただのデータ転送オブジェクトと化してしまいます。
Q3. 関心の分離における3つの関心領域のうち、最も変更頻度が低いのはどれですか？
- A) プレゼンテーション
- B) アプリケーション
- C) ドメイン
- D) インフラストラクチャ
答えを見る
正解: C
ドメイン層はビジネスルールを表現するため、ビジネス自体が変わらない限り安定しています。「注文はキャンセルできる」「在庫がないと出荷できない」などのルールは、使用するデータベースやフレームワークが変わっても変わりません。一方、インフラストラクチャ層は技術の入れ替えや外部サービスの変更で頻繁に変わります。
Q4. 依存性逆転の原則をアーキテクチャレベルで適用する方法として正しいのはどれですか？
- A) Service層からRepository層を直接呼び出す
- B) ドメイン層にインターフェースを定義し、インフラ層がそれを実装する
- C) インフラ層にインターフェースを定義し、ドメイン層がそれを実装する
- D) Controller層がデータベースに直接アクセスする
答えを見る
正解: B
依存性逆転の原則をアーキテクチャに適用するには、安定した内側の層（ドメイン）にインターフェース（Port）を定義し、不安定な外側の層（インフラ）がそのインターフェースを実装（Adapter）します。これにより、ドメインはインフラの詳細を知らずに済み、依存の方向が外側から内側に向かいます。
Q5. ヘキサゴナルアーキテクチャ、オニオンアーキテクチャ、クリーンアーキテクチャに共通する原則として誤っているものはどれですか？
- A) ドメインが最も内側に位置する
- B) 依存は外側から内側に向かう
- C) レイヤー間は必ず具象クラスで接続する
- D) インフラストラクチャの差し替えが容易
答えを見る
正解: C
3つのパターンに共通する原則は「ドメイン中心」「依存は内向き」「インターフェースによる分離」「技術の交換可能性」です。レイヤー間はインターフェース（Port）で接続するのが原則であり、具象クラスで直接接続するとレイヤー間の結合度が高くなってしまいます。
Q6. 以下のディレクトリ構造で、依存の方向として正しいのはどれですか？
src/
├── domain/
│ └── ports/out/OrderRepository.ts (interface)
├── application/
│ └── CreateOrderUseCase.ts
└── adapters/
└── out/PrismaOrderRepository.ts (implements OrderRepository)- A) domain → adapters
- B) adapters → domain
- C) application → adapters
- D) domain → application
答えを見る
正解: B
PrismaOrderRepository（adapters層）はOrderRepositoryインターフェース（domain層）を実装しています。つまり、adapters層がdomain層に依存しています。これが依存性逆転の原則の実践です。applicationのCreateOrderUseCaseもdomain層のインターフェースに依存するため、依存は常に内側（domain）に向かっています。
Q7. ADR（Architecture Decision Record）に含めるべき要素として最も重要でないものはどれですか？
- A) 決定の理由とコンテキスト
- B) 却下した選択肢とその理由
- C) 実装に使用するコードの全行
- D) 決定のステータス
答えを見る
正解: C
ADRは設計判断とその理由を記録する軽量なドキュメントです。コンテキスト、決定内容、理由、却下した選択肢、ステータスが主な構成要素です。実装コードの全行を含める必要はなく、それはソースコード自体が担う役割です。ADRの目的は「なぜそう決めたのか」を記録することです。
Q8. レイヤードアーキテクチャの限界として挙げられる「ショートカット」問題とは何ですか？
- A) コードが短すぎて読みにくくなる問題
- B) コントローラーがサービス層を飛ばしてリポジトリ層に直接アクセスしてしまう問題
- C) テストコードを省略してしまう問題
- D) ドキュメントを書かない問題
答えを見る
正解: B
レイヤードアーキテクチャでは、「単純な処理だからServiceを経由しなくていい」という理由で、上位層が下位層を飛ばしてアクセスするショートカットが生まれがちです。これにより層の境界が崩壊し、依存関係が複雑化します。結果として、変更の影響範囲が予測できなくなり、スパゲッティコード化します。
結果
7問以上正解の場合
合格です。おめでとうございます。
Step 1「アーキテクチャ思考の目覚め」を完了しました。 次は Step 2「ヘキサゴナルアーキテクチャ」に進みましょう。
6問以下の場合
もう少し復習しましょう。
間違えた問題の内容を、該当するセクションで復習してください：
| 問題 | 復習セクション |
|---|---|
| Q1 | step1_1 なぜアーキテクチャが必要なのか |
| Q2 | step1_2 レイヤードアーキテクチャの限界 |
| Q3 | step1_3 関心の分離と依存性の方向 |
| Q4 | step1_3 関心の分離と依存性の方向 |
| Q5 | step1_4 アーキテクチャパターンの全体像 |
| Q6 | step1_3 / step1_4 依存性の方向 |
| Q7 | step1_5 ADR |
| Q8 | step1_2 レイヤードアーキテクチャの限界 |
Step 1 完了
お疲れさまでした。
学んだこと
- アーキテクチャが解決する問題（影響範囲、テスト、分担、技術交換）
- レイヤードアーキテクチャの4つの限界
- 関心の分離と依存性の方向
- 3つのアーキテクチャパターンの共通点と違い
- ADRによる設計判断の記録
次のステップ
Step 2: ヘキサゴナルアーキテクチャ（4時間）
いよいよ具体的なアーキテクチャパターンの学習に入ります。Ports & Adaptersの概念を深く理解し、実際にコードを書いて身につけましょう。
推定所要時間: 15分