知り合いのu1hoshinoががんばってAP設計のノウハウをまとめはじめたようです。手始めはコンテキストですが、前半の概念を導入している部分でいろいろ消化不良感があったのでコメントに書こうと思ったのですが、長くなりそうだったのでこっちに書きます。脳内ダンプ的なものなので、特に結論はないです。
コンテキストって何
計算機の話に限定すれば、「コンテキスト」は「特定の計算における環境」だと言えます。ここで言う「環境」としては、広義には言語やランタイムを表すこともありますが、今回は（元記事の想定に基づいて）「変数と値のセット」に限定します。
特定の計算を構成する命令（ステートメント）を、何かしらの形（関数、プロシージャ、クラス…）でモジュール化することを考えた場合、計算に必要な入力値すべてを引数や戻り値で渡せば、環境は不要になります。実際、純粋関数型言語ではこのようにして計算を組み立てます。しかし、モジュール（の複数の命令）をまたがって同じ情報を繰り返し参照するなら、その情報はパラメータで渡すのではなく、環境として設定してどこからでも参照できるようにすることで、モジュール間の結びつきが煩雑化するのをある程度抑えられます。これが、コンテキストを利用する比較的大きな理由だと思います。
# 他方で、抽象化された「環境」を引数や戻り値として受け渡していくことで、副作用を排除しつつモジュールの煩雑化を防ぐ、モナドのようなアプローチもあります。
何故Webでコンテキストを作るのか？
Javaで標準的なWebインフラ（Servlet）には、組み込みでリクエスト・セッション・アプリケーションなどのコンテキストオブジェクトが存在しており、自由に利用できます。
これらのコンテキストにはServlet内から自由にアクセスできるため、まさに「特定のリクエスト実行における環境」になっており、Servlet内部に命令を書いている限り、これらがまさにコンテキストとして機能したはずです。
しかし現状では、レイヤパターンの適用によってリクエスト処理を複数モジュールに分割し、Webレイヤ以外では上記のコンテキストは使えないように設計するのが一般的になりました。これによって、ビジネスロジックと呼ばれる命令群が特定インフラへ依存することは少なくなったものの、コンテキストの喪失によって最初に設定した問題が発生することになりました。これを解決するために、Web非依存の独自コンテキストを再設計している、というのが元記事で言うところの「コンテキスト」が誕生した経緯です。
コンテキスト情報として何を設定する？
これは、計算の性質や、どのようにモジュール分割するかによって変わりそうです。また、リクエスト処理のコンテキスト設定がアプリケーションプログラム側で許可されていないケースも多く、基盤や（APじゃない）アーキテクチャが把握できる範囲となると、相当広範囲で共通的に使われるものに限られるケースが多くなります。結果的に、元記事でも書いてあるような
- ユーザー情報
- 日付
などが多くなるわけですね。
また、コンテキスト情報として設定するものの中で、レイヤ指針に反するような内容を設定した場合、不適切な依存関係が発生する可能性があるので注意する必要があります。ビジネスロジックをインフラから切り離すためのレイヤ化だったのに、コンテキストに端末IDやIPアドレスが設定されていると、ロジックがこれらに依存する可能性があります。単なるデータとして扱っているうちは良いですが、不用意にインフラに特化した「型」に依存してしまうと、物理モジュールの管理が面倒になるので、注意が必要です。
結局
結局、「コンテキスト」が何で、どうして必要なのかを自分の中でもう少し整理しておきたかったというわけでした。書いてみると当たり前というか、しょーもない話ですね。
コメント