Clean Architecture・SOLID・DIPを改めて整理してみた — AI駆動開発の時代にまだ使えるのか？

// NG: UserServiceが認証もメール送信もDB永続化も担当
class UserService {
  authenticate() { ... }
  sendEmail() { ... }
  saveToDb() { ... }
}

// OK: 責務ごとに分離
class AuthService { authenticate() { ... } }
class EmailService { sendEmail() { ... } }
class UserRepository { save() { ... } }

// NG: フォーマット追加のたびにif文を修正
if (type === "pdf") { ... }
else if (type === "csv") { ... }

// OK: 新しいクラスを追加するだけ
interface Exporter { export(data: Data): void }
class PdfExporter implements Exporter { ... }
class CsvExporter implements Exporter { ... }  // 追加するだけ

// NG: Penguinはflyの契約を破る（Birdとして置換できない）
class Bird { fly(): void { ... } }
class Penguin extends Bird {
  fly() { throw new Error("ペンギンは飛べない") }  // 契約違反
}

// OK: 飛べるかどうかで抽象を分ける
interface Bird { eat(): void }
interface FlyingBird extends Bird { fly(): void }
class Sparrow implements FlyingBird { ... }
class Penguin implements Bird { ... }  // flyを持たないので置換問題が起きない

// NG: 1つの巨大インターフェース。印刷専用機もscan/faxの実装を強制される
interface Machine { print(): void; scan(): void; fax(): void }

// OK: 役割ごとに分離。必要なものだけ実装すればよい
interface Printer { print(): void }
interface Scanner { scan(): void }
class SimplePrinter implements Printer { print() { ... } }

class StripePayment {
  charge(amount: number) { /* Stripe API呼び出し */ }
}

class OrderService {
  private payment = new StripePayment()  // ← 直接依存
  placeOrder(amount: number) {
    this.payment.charge(amount)
  }
}

// 1. 抽象（インターフェース）を定義
interface PaymentGateway {
  charge(amount: number): void
}

// 2. 高レベルは抽象に依存
class OrderService {
  constructor(private payment: PaymentGateway) {}
  placeOrder(amount: number) {
    this.payment.charge(amount)
  }
}

// 3. 低レベルが抽象を実装
class StripePayment implements PaymentGateway {
  charge(amount: number) { /* Stripe API */ }
}

class PayPalPayment implements PaymentGateway {
  charge(amount: number) { /* PayPal API */ }
}

class FakePayment implements PaymentGateway {
  charge(amount: number) { /* テスト用 */ }
}

// ドメイン層がインターフェースを定義
interface UserRepository {
  findById(id: string): User
  save(user: User): void
}

// インフラ層が実装を提供
class PostgresUserRepository implements UserRepository {
  findById(id: string) { /* SQLクエリ */ }
  save(user: User) { /* INSERT/UPDATE */ }
}

// ユースケースはインターフェースだけを知っている
class CreateOrder {
  constructor(private users: UserRepository) {}
  execute(userId: string) {
    const user = this.users.findById(userId)  // Postgresかどうか知らない
    // ビジネスロジック...
  }
}

// ORMなし（生SQL）
const result = await db.query('SELECT * FROM users WHERE id = $1', [1])

// ORMあり（Prisma）
const user = await prisma.user.findUnique({ where: { id: 1 } })

// PrismaがすでにきれいなAPIを提供している
const user = await prisma.user.findUnique({ where: { id } })

// Repositoryでさらにラップ... 冗長では？
class UserRepository {
  findById(id: string) {
    return prisma.user.findUnique({ where: { id } })
  }
}

// ストア層（Repositoryの実装に相当）: localStorageの詳細を隠す
class ItemStore {
  static load(key: string): Item[] {
    const raw = localStorage.getItem(key)
    return raw ? JSON.parse(raw) : []
  }

  static save(key: string, items: Item[]): void {
    localStorage.setItem(key, JSON.stringify(items))
  }
}

// ユースケース層: localStorageの存在を知らない
class ItemUsecase {
  static add(key: string, item: Item): void {
    const current = ItemStore.load(key)
    // ビジネスルール: 重複チェック、上限管理...
    const updated = [item, ...current].slice(0, 50)
    ItemStore.save(key, updated)
  }
}

✅ 良いUse Case名（人間のアクション）:
  PlaceOrder          ← 「注文する」
  RegisterUser        ← 「ユーザー登録する」
  CancelSubscription  ← 「サブスクを解約する」
  TransferMoney       ← 「送金する」

❌ 悪いUse Case名（システムの機械的処理）:
  InsertOrderRecord   ← DBの操作を表している
  UpdateUserTable     ← テーブル名が出てくる時点でNG
  SendHttpRequest     ← 通信手段の詳細
  ValidateAndPersist  ← 何のバリデーション？何を永続化？

class PlaceOrder {
  constructor(
    private orders: OrderRepository,
    private payments: PaymentGateway,
    private notifications: NotificationService
  ) {}

  execute(userId: string, items: CartItem[]) {
    // ビジネスルールはここに書く
    const order = Order.create(userId, items)

    if (order.total() > 10000) {
      throw new Error("注文上限を超えています")
    }

    // どうやって保存する？ 知らない。Repositoryに任せる
    this.orders.save(order)

    // どうやって決済する？ 知らない。Gatewayに任せる
    this.payments.charge(order.total())

    // どうやって通知する？ 知らない。Serviceに任せる
    this.notifications.notifyOrderPlaced(order)
  }
}

// ❌ Use Caseに機械的・データ層の処理が入っている
class PlaceOrder {
  execute() {
    // SQLがUse Caseに — NG
    await db.query('INSERT INTO orders VALUES...')

    // HTTP通信の詳細がUse Caseに — NG
    await fetch('https://api.stripe.com/charges', { headers: ... })

    // キャッシュロジックがUse Caseに — NG
    await redis.set(`order:${id}`, JSON.stringify(order))
  }
}

// Entity: 自分自身に関する不変条件
class Order {
  addItem(item: CartItem) {
    if (this.items.length >= 50) {
      throw new Error("1注文50品まで")  // ← Entity自身のルール
    }
    this.items.push(item)
  }
}

// Use Case: エンティティ横断のルール、フロー制御
class PlaceOrder {
  execute(userId: string, items: CartItem[]) {
    const user = this.users.findById(userId)

    if (user.isSuspended()) {
      throw new Error("停止中のアカウント")  // ← 複数エンティティにまたがるルール
    }

    const order = Order.create(userId, items)
    // ...
  }
}

ProcessExpiredSubscriptions  ← cronジョブが起動、人間ではない
RecalculatePricing           ← イベント駆動
SyncInventoryFromWarehouse   ← 定期連携

// Repository（ストア層）: ストレージ操作を表す動詞
class ItemStore {
  static load(key: string): Item[]  // ストレージから読み込む
  static save(key: string, items: Item[]): void  // ストレージに書き込む
}

// Use Case: ユーザーのアクションを表す動詞
class ItemUsecase {
  static list(key: string): GroupedItems  // ユーザーが「一覧を見る」
  static add(key: string, item: Item): void  // ユーザーが「追加する」
  static remove(key: string, id: string): void  // ユーザーが「削除する」
}

// 月曜: Stripe
const app = new OrderService(new StripePayment())
// 火曜: CEOがPayPalに変更と言った
const app = new OrderService(new PayPalPayment())
// OrderServiceのコードは一切変更なし

const fake = new FakePayment()
const service = new OrderService(fake)
service.placeOrder(100)
// 本物のStripeは呼ばれない。ミリ秒で完了

チームA: PaymentGatewayインターフェースに対してOrderServiceを実装
チームB: PaymentGatewayインターフェースを実装してStripePaymentを作成
→ インターフェースが契約。お互いを待つ必要がない

インターフェースなし: DBライブラリ変更 → importしている全ファイルを修正
インターフェースあり: DBライブラリ変更 → 新しい実装クラスだけ修正

// フォーマルなDIP: インターフェース + 実装クラス（正統派）
interface ItemRepository { load(): Item[]; save(items: Item[]): void }
class LocalStorageItemRepository implements ItemRepository { ... }

// 実用的な分離: 静的クラスでレイヤーを分ける（インターフェースなし）
class ItemStore { static load(): Item[] { ... }; static save(): void { ... } }
class ItemUsecase { static list(): Item[] { return ItemStore.load() } }

シンプルなCRUD API → フラット構造、Repositoryパターン不要
中規模アプリ       → サービス層 + Repository、軽い分離
複雑なドメイン     → Clean Architecture + DDDが効果を発揮