フロントエンド発のFeature-Sliced Designを、自作のRust製ゲームエンジンに持ち込んだ話

トークタイトル（70文字以内）#

フロントエンド発のFeature-Sliced Designを、自作のRust製ゲームエンジンに持ち込んだ話

トーク概要（1000文字以内）#

「これ、どこに置けばいい？ 半年後の自分は、ちゃんと見つけられる？」

これは、わたしが個人開発でずっと抱えてきたモヤモヤです。

本職はインフラエンジニアでSRE。反復作業を削るのが日課です。趣味でRust + Bevy + Dioxus desktopで自作のゲームエンジン/エディタを作っています。そのエディタを書き進めるうち、ドメインオブジェクトとCRUD機能が増えていく予感に、手が止まることがありました。「ここに置いた理由を、半年後の自分が覚えていられない」。配置に毎回悩むコストが、スピードを確実に削っていく感覚。

悩むなかで出会ったのが、フロントエンド界隈で広まっているFeature-Sliced Design (FSD)でした。app / pages / widgets / features / entities / sharedの6レイヤーに分け、同レイヤー間の依存を禁止する。「どこに置くか」をレイヤー名で機械的に決められる設計思想です。

それがRustのdesktopアプリで通用するのか？　半信半疑でエディタ部分を組み直してみたら、禁止されているレイヤー間の依存はそのままbuild errorで止まるようになりました。Webフロントエンドではlinterで頑張っていた境界の強制が、Rustではコンパイラ標準で手に入る。フロントエンド発のアーキテクチャが、自作ゲームエンジンのエディタで綺麗にハマりました。

この「どこに置くか」がレイヤー名で決まる仕組みは、AIエージェントと一緒にコーディングするときに、さらに効果的になりました。AIが禁止された依存を書いてきても、Rustが即build errorで止めてくれる。プロンプトにも、明日の自分にも、半年後の自分にも、AIエージェントにも、レイヤー名がそのまま通じます。みんな、わたしのコードを”読みに来る”側 ─ 画面の向こうの読者です。レイヤー名さえあれば、迷子になりにくいです。

本セッションでは、フロントエンド発のアーキテクチャが、自作ゲームエンジン/エディタの開発で噛み合った越境体験を共有します。RustとAIに増幅された個人開発の実感を、言語もドメインも越えるアーキテクチャ移植のレシピとして持ち帰っていただきたいです。