はじめに
多くのプロジェクトでは「まずデータベースを決める」ところから設計が始まります。
しかし、Robert C. Martin（Uncle Bob）は 「データベースは詳細にすぎない」 と強調します。
つまり、ビジネスルールやユースケースよりもデータベースが優先されるべきではない ということです。
1. 「データベースは詳細」とはどういう意味か？
- データベースはアプリケーションの中心的なルールではない
- それは 実装技術のひとつ に過ぎない
- 本当に重要なのは ビジネスルール（Entities, Use Cases）
例：
あなたの会社の「注文処理」ルールは、MySQL を使おうが PostgreSQL を使おうが変わらないはずです。
2. レイヤーの中での位置付け
Clean Architecture の同心円モデルでは、データベースは一番外側に置かれます。
- Entities, Use Cases … 内側のビジネスロジック
- DB … 外側の Frameworks & Drivers に属する技術的詳細
3. 実装例（Kotlin）
// 内側: ビジネスルール
data class User(val id: String, val name: String)
// 境界: 抽象化された Repository
interface UserRepository {
fun findById(id: String): User
}
// 内側: ユースケース
class GetUserUseCase(private val repo: UserRepository) {
fun execute(id: String): User = repo.findById(id)
}
// 外側: DB 実装（詳細）
class SqlUserRepository : UserRepository {
override fun findById(id: String): User {
// SQL 実行
return User("123", "Taro")
}
}
→ ユースケース（ビジネスロジック）は SQL を知らない
→ DB を差し替えてもビジネスロジックは一切変更不要
4. なぜ「データベースは詳細」なのか？
-
技術は移り変わる
- MySQL → PostgreSQL → NoSQL（MongoDB, DynamoDB）
- クラウド移行（RDS → Firestore など）
- 技術寿命はビジネスルールより短い
-
ビジネスは技術に依存しない
- 「注文」「請求」「在庫」といった概念は、DB とは無関係に存在する
-
テスト容易性
- DB をモック化すれば、ユースケースのテストが軽量に可能
5. よくあるアンチパターン
- 「まずテーブル設計」から始める
-
UserDaoを直接ユースケースで呼び出す - DB の都合（外部キーや正規化）がビジネスルールを縛ってしまう
これらはすべて、ビジネスロジックが詳細に引きずられている状態 です。
まとめ
- データベースは アプリケーションの中心ではない
- それは単なる 詳細（Detail） にすぎない
- ビジネスルールやユースケースこそがアーキテクチャの中心
- 「DB 依存のコード」は外側に押し出し、内側から切り離すべき
Clean Architecture が目指すのは「ビジネスロジックは不変・技術は入れ替え可能」という構造です。
その象徴的なフレーズが 「The Database is a Detail」 なのです。