Kotlin

言語別の既定§2-6

既存のJava資産との連携、複雑な業務ルール、大規模バッチ、Kafkaなどのストリーム処理で選ぶ。

選ぶ場面§2-10

• 既存のJava資産（社内基盤、外部の業務パッケージ）と密に連携する
• 複雑な業務ルールと厳密な状態管理sealed classなどで状態を型で表現しやすく、トランザクションやバッチの基盤が成熟している
• 大規模バッチ再実行・中断再開・分割実行の仕組みが揃っている
• ストリーム処理Kafka周辺のエコシステムがJVM中心

既定：非同期Kotlin（JVM）

代替：CRUD中心のWebアプリ・管理画面作成物ごとの言語の決め方

既定は Rails（画面の多い業務システムを最も速く作れる）。業務ルールが非常に複雑で、既存のJava資産と連携するとき に乗り換える。

代替：モバイルアプリ作成物ごとの言語の決め方

既定は React Native＋Expo。端末機能を深く使うとき に乗り換える。

採用の根拠§22-2

JVMの成熟したトランザクション・バッチ・ストリーム処理の基盤をそのまま使え、Javaより簡潔で安全に書ける。既存のJava資産と直接連携できる

「重いのでは」→ 起動時間が問題になる用途（サーバーレス）以外では、常駐サーバーとして十分な性能が出る