はじめに

多くのプロジェクトでは「まずデータベースを決める」ところから設計が始まります。
しかし、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」 なのです。