軽量Webフレームワークで学ぶコード分割の考え方

前提

この内容は「正解がこうだ」という話をしたいわけではなく、コードを分割する過程を共有することで話者なりの考え方を伝えるものです。これまでの経験や読んだ文献などで作られた一つの考え方として参考にしてください。

分割のポイント

今回は以下のような観点を大事にして最初の分割をしていきました。

アプリケーションの動作と、設定など

アプリケーション（業務）の仕様に合わせているコードの塊と、設定などの集約されたコードから分けました。理由としては以下のような事柄を伝えています。

• 意味的な内容の分割（設定のような基盤的な部分と、アプリケーションの実装の部分）
• アプリケーションの実装の過程で変化しやすい（不安定な）部分とそうでない（安定な）部分の分割
• 一緒に変更されやすいものがまとまるように分割

フレームワークとライブラリ

フレームワークという言葉も広義・狭義のようなものがありますが、狭義のフレームワークの話を軽く書いておきます。フレームワークは「設計の再利用」をする為の仕組みです。「実装の再利用」を目的とするライブラリとはこの点が大きく違います。

ライブラリは具体的にコードを呼び出す主体はアプリケーションコードを書いているプログラマであることがほとんどです。フレームワークの場合、フレームワークの決まりに沿ってコードを書いておくと、そのコードはフレームワークの決めたタイミングで勝手に呼び出されます。

「Don't call us. We'll call you（私たちを呼ぶな。私たちが呼ぶ）」 この言葉で示されるような「呼び出す側」としてのポジションをフレームワークは取ります。

動画の中では 「『routes.jsで関数を公開しておけばindex.js側から勝手に呼び出される仕組み』を用意しておき、routes.jsの中身はアプリケーションコードを作成するプログラマが自由に書いて置いておける」 という考え方を「フレームワーク的」と称していました。index.jsがフレームワークのように振る舞うイメージです。

アプリケーションの規模感とコード分割

動画中で扱ったコードは「その規模感でコードが増えないのであれば、特に分割などしなくても問題ない」と考えても良いようなコード量でした。だとすればある程度問題が露呈するまでこのまま進むのもアリだと思います（YAGNI的な考え方）。今回は「今後本格的な実装をドンドン入れていく前提において、どのように準備しておくと良さそうか」という文脈で捉えてください。

複数のテーブルの情報を扱う場合にどうする？

シンプルに1テーブル（や、それに密接に関係する）の情報をCRUDするだけならば今の実装の延長で良いけれども、複数のテーブルの情報を操作するようなロジックが発生した時にはどのように対応するのか考える必要があります。この動画では例えば以下のようなことを考える事がありそうだと話し合っています。

全体の統一性

• シンプルなCRUD操作も含めて全て同じ設計に統一するか
• アクションごとにどのように対応するか選択するか

永続化データの層をさらに分けるかどうか

• 永続化データを扱う部分と、業務ロジックを扱う部分を分けるべきかどうか