レイヤードアーキテクチャとリポジトリ（ローカル実施）

導入

良いモデルも、DBアクセスやHTTP処理と混ざると台無しです。レイヤードアーキテクチャはコードを役割の層に分け、依存の向きを一方通行にします。鉄則は「Domain層は誰にも依存しない」です。

図解

flowchart TB
    P["Presentation層<br/>入出力（API・画面）"]
    A["Application層<br/>ユースケース（手順）"]
    D["Domain層 ★主役★<br/>業務ルール＋リポジトリの契約(interface)"]
    I["Infrastructure層<br/>技術詳細（DB・外部API）"]
    P --> A --> D
    I -. "実装が契約に依存（依存性逆転）" .-> D
    style D fill:#fff3e0,stroke:#e65100,stroke-width:3px

進め方

1. スターター115-layered/starter.zipを展開し、LayeredLesson.slnを開く
2. Program.cs・各層のTODOを埋める

学ぶこと

• 「保存」はリポジトリというインターフェースとしてDomain層に置き、実装だけInfrastructure層に置く（DIPの実戦投入）
• Domain層は他の層を一切参照しない（業務ルールをDBやUIの都合から守る）
• Application層は「注文する」などのユースケースの手順を組み立てる（Facade的役割）

// Domain層: リポジトリの「契約」だけを置く（実装は書かない）
public interface IOrderRepository { void Save(Order order); Order? FindById(int id); }

// Infrastructure層: 契約の実装（EF Coreなど）はここに置く
public class EfOrderRepository : IOrderRepository { /* ... */ }

期待される出力

注文を保存しました（Domain層はDBを知らないまま動作）

まとめ

• レイヤードアーキテクチャは役割で層を分け、依存を一方通行にする
• Domain層は誰にも依存しない（リポジトリはインターフェースで表現）
• DIPの実戦投入

テンプレート構成（教材制作用メモ）

115-layered/
├── starter.zip   # 4層構成のプロジェクト / 各層のTODO
└── solution/