はじめに
多くのプロジェクトでは最初にこう考えがちです。
- 「Spring Boot を使って何を作ろうか？」
- 「Rails のモデル設計はどうする？」
- 「Flutter の Widget 構成は？」
しかし Robert C. Martin（Uncle Bob）は 「フレームワークは詳細にすぎない」 と述べています。
つまり、フレームワークを中心に設計してはいけない ということです。
1. フレームワークは「道具」にすぎない
- フレームワークは便利だが、アプリケーションの本質ではない
- DB、Web、UI すべて「フレームワークやライブラリ」によって変わる
- しかし ビジネスルールはそれらに依存しないはず
フレームワークは「使い捨ての道具」、ビジネスロジックこそが長持ちする資産。
2. Clean Architecture の同心円における位置づけ
- 中心（Entities, UseCases） = アプリの本質
- 外側（Frameworks） = 技術的詳細（DB, Web, UI, FW）
フレームワークは一番外側にある「可変要素」にすぎません。
3. 実装例（Kotlin + Spring Boot）
// 内側: ビジネスルール
data class Order(val id: String, val total: Int)
interface OrderRepository {
fun save(order: Order)
}
// 内側: ユースケース
class PlaceOrderUseCase(private val repo: OrderRepository) {
fun execute(order: Order) {
if (order.total <= 0) throw IllegalArgumentException("金額が不正")
repo.save(order)
}
}
// 外側: フレームワークに依存する実装
@Repository
class JpaOrderRepository(private val jpaRepo: SpringDataOrderRepo) : OrderRepository {
override fun save(order: Order) = jpaRepo.save(order.toEntity())
}
// 外側: Web コントローラ
@RestController
class OrderController(private val useCase: PlaceOrderUseCase) {
@PostMapping("/orders")
fun place(@RequestBody req: OrderRequest) {
useCase.execute(Order(req.id, req.total))
}
}
-
PlaceOrderUseCaseは Spring も JPA も知らない - DB・Web・フレームワークが変わってもユースケースは変わらない
4. なぜ「フレームワークは詳細」なのか？
-
流行り廃りが激しい
- Struts, JSF, GWT, AngularJS… かつて流行したが今は廃れた技術
- でもアプリのルールは残る
-
フレームワークは選択肢のひとつに過ぎない
- Kotlin: Spring Boot / Ktor / Micronaut
- Flutter: Riverpod / Bloc / Provider
- どれを選んでもビジネスルールは同じ
-
本質はビジネスロジック
- 技術に依存させないことで、テスト容易性・長期的な保守性を確保
5. よくあるアンチパターン
- 「Spring Boot の機能を中心に設計してしまう」
- 「Rails の ActiveRecord モデルがそのままドメインモデル」
- 「Flutter の Widget に直接ビジネスロジックを書く」
→ これらはすべて フレームワークが主役になってしまった構造。
本来、フレームワークはただの道具 に過ぎません。
まとめ
- Frameworks are Details = フレームワークは外側の詳細であり、アプリの本質ではない
- ビジネスロジック（Entities, UseCases）は フレームワークに依存しない 形で設計すべき
- フレームワークを選ぶのは最後でよい。中心は常に ビジネスルール
つまり、「技術に振り回されない設計」 こそが Clean Architecture の目的なのです。