長期運用と依存戦略

全部入りにしない理由。依存の主導権はアプリ側に残します。

標準機能の範囲

Naifyは、HTTPの入口、ルーティング、RequestContext、Controllerディスパッチという骨格に責務を絞り、認証、バリデーション、キャッシュ、ジョブ、テンプレート、DB層などはアプリごとに選べるようにしています。

ここで重視しているのは、フレームワークが選んだ依存をアプリ全体の前提にしないことです。最初から全部を抱え込まなければ、あとから差し替える余地も残しやすいです。

必要な機能は、案件に応じてライブラリや追加パッケージを組み合わせます。

この判断がどんな長期運用システムの課題から出てきたかは長期運用システムの課題にまとめています。

Naify自体はComposerを必須にしていませんが、アプリ側でComposerを使うこともできます。重要なのは、依存の選定権をフレームワークではなくアプリ側が持つことです。

Composerを避けたいのではなく、フレームワーク本体の寿命を特定の依存と結びつけすぎないことを優先しています。

どのフレームワークでも、採用するだけで設計規約が守られるわけではありません。チームで決めた処理の配置や呼び出し順が守られないと、変更の影響を把握しにくくなり、不具合や保守負担につながります。

たとえば、共通の認証処理を通さない経路ができたり、複数の画面に同じ業務処理が分散したりすると、確認漏れや修正漏れが起こりやすいです。

Naifyでも、このリスクは同じです。共通処理をBaseControllerなどにまとめ、役割分担をコード上で確認しやすくします。規約の共有に加え、レビューとテストで実装を確認することを重視しています。

規約が複数の文書や実装に分散すると、途中から参加した人が判断に迷いやすいです。共通の処理と例外の扱いを明確にし、変更時に確認する場所を絞ります。

Naifyでは、認証やログなどの実装を案件に応じて選びます。実装前に担当する層と利用方法を共有し、選んだ理由を残しておきます。