クリーンアーキテクチャは過剰設計だった — 3年運用して気づいた現実

クリーンアーキテクチャ、3年間信じてた

Robert C. Martinの「Clean Architecture」を読んで感銘を受け、3年間ガチで実践した。UseCase層、Entity層、Repository層、Gateway層...全部きっちり分けた。結果どうなったか。コードベースが肥大化して、チームの開発速度が半分に落ちた。

レイヤー分離の罠

クリーンアーキテクチャの問題は「すべてのプロジェクトに同じ分離度を適用する」こと。ユーザー登録の機能を作るだけで、こんなファイルが必要になる：

// 必要なファイル数
src/
├── domain/entities/User.ts
├── domain/repositories/IUserRepository.ts
├── application/usecases/RegisterUser.ts
├── application/dtos/RegisterUserRequest.ts
├── application/dtos/RegisterUserResponse.ts
├── infrastructure/repositories/UserRepository.ts
├── presentation/controllers/UserController.ts
└── presentation/mappers/UserMapper.ts
// 8ファイル。CRUDひとつで8ファイル。

小〜中規模のプロジェクトでこれは過剰。新メンバーが入るたびに「なんでこんなにファイルがあるんですか」と聞かれる。

依存性逆転の原則、本当に必要？

「DBをいつでも切り替えられるようにRepositoryを抽象化する」——これ、実際にDBを切り替えたことある人いる？僕の経験では一度もない。YAGNI（You Aren't Gonna Need It）の典型。実際にはPrismaやDrizzleのようなORMに直接依存した方が開発速度は上がる。

代替案 — 「ちょうどいい」設計

僕が今採用してるのは、もっとシンプルな構成。Server Actionsにビジネスロジックを書き、共通処理だけ関数に切り出す。テストは必要な部分だけ書く。

// これで十分
src/
├── actions/register-user.ts    // ロジック＋DB操作
├── lib/validate-email.ts       // 共通バリデーション
└── __tests__/register-user.test.ts

3ファイル。読めば全体が分かる。テストも書きやすい。

設計は「プロジェクトの規模」で決めろ

クリーンアーキテクチャが間違いとは言わない。100人以上のチームで数年間開発する巨大プロジェクトなら正当化される。でも10人以下のチームで、寿命が2-3年のプロダクトに適用するのは過剰設計。設計思想に酔って、プロダクトの成長を止めるのは本末転倒だ。