はじめに

多くのプロジェクトは「どの Web フレームワークを使うか？」からスタートします。
Rails? Spring? Django? Express?

しかし Robert C. Martin（Uncle Bob）は 「Web は詳細にすぎない」 と言います。
つまり、アプリケーションの中心は Web 技術ではなく、ビジネスルール です。

1. 「Web は詳細」とはどういう意味か？

Web は単なる インターフェース のひとつ
HTTP, JSON, REST, GraphQL … これらは データのやり取り方法 に過ぎない
本当に重要なのは ユースケースやビジネスロジック

たとえば「注文処理」のルールは、REST API だろうが CLI だろうが変わりません。

2. レイヤーの中での位置付け

Clean Architecture の同心円モデルにおいて、Web フレームワークやコントローラは外側の層 に位置します。

内側：Entities（ドメイン）、UseCases（アプリのルール）
外側：Web（REST Controller, Servlet, Router など）

3. コード例（Kotlin + Spring）

// 内側: ビジネスルール
data class User(val id: String, val name: String)

interface UserRepository {
    fun findById(id: String): User
}

class GetUserUseCase(private val repo: UserRepository) {
    fun execute(id: String): User = repo.findById(id)
}

// 外側: Web (Spring Controller)
@RestController
class UserController(private val useCase: GetUserUseCase) {

    @GetMapping("/users/{id}")
    fun getUser(@PathVariable id: String): UserResponse {
        val user = useCase.execute(id)
        return UserResponse(user.id, user.name)
    }
}

data class UserResponse(val id: String, val name: String)

→ ユースケース（ビジネスロジック）は Spring も @GetMapping も知らない
→ Web フレームワークを切り替えても、ユースケースはそのまま

4. なぜ「Web は詳細」なのか？

技術は流行り廃りが激しい
- JSP → Struts → Spring → Ktor → Micronaut → …
- 10年後も同じ Web フレームワークを使っているとは限らない
UI/通信方式は変わってもルールは残る
- Web API → モバイルアプリ → IoT デバイス
- どの「入り口」からでも使えるようにしておくのが理想
テスト性・移植性
- ユースケースをフレームワークに依存させないことで、ユニットテストが容易

5. よくあるアンチパターン

「Controller にユースケースのロジックを全部書く」
「Spring のアノテーションを Entity に直書き」
「REST API の設計＝ビジネスロジック設計」になっている

これらはすべて、ビジネスが Web フレームワークに支配されている状態 です。

まとめ

Web は アプリの本質ではなく、外部の詳細
重要なのは ユースケース（アプリのルール）
Web フレームワークは単なる「入り口」に過ぎない
アーキテクチャの中心は ビジネスロジック に置くべき