Jotai への移行途中で見えた構造的課題 - ENECHANGE Developer Blog

こんにちは、ENECHANGE でエンジニアをしている清水です。 今年の7月に電力料金シミュレーション領域のチームへジョインしました。 当時、チームではフロントエンドの状態管理の複雑さを解消するため、 Jotai への移行が進められていました。 しかし、実際にコードを追うにつれ、根本的なつらさの原因は状態管理の手段ではなく「判定の所在」という構造そのものにあることに気づきました。 本記事では、5回の「なぜ」で真因に辿り着き、仕組みを足さずに判定の所在を変えるだけで解決した過程をご紹介します。 状態管理における課題 同期の置き場所が変わっただけだった 5回の深掘りで辿り着いた真因 因果の向きが真逆だった 「道具の層」と「構造の層」のズレ 解決策：判定をドメインへ返す 同期（PUSH）から参照（PULL）への構造転換 データと判定の分離フロー オーケストレーターを God 化させない設計 段階