設計制約が、意味を残す
Resource、Ray.Di、AOP、Contextに責務を分けることで、アプリケーションの意味がコントローラー、設定、暗黙の規約へ散らばりません。コードを読めば、何が入力で、何に依存し、どの表現へ出るのかを追えます。
Value
技術的特徴を、持続する価値へ。
BEAR.Sundayの価値は、生産性、拡張性、パフォーマンスといった一般語だけでは説明しきれません。価値の源泉は、Resource、context-agnostic DI、AOP、CDN中心のRead Modelが、設計から運用まで同じ意味を保つところにあります。このページは、技術がどう価値に変わるか、その因果をたどります。
From mechanism to value
価値は、機能の数ではなく、制約の質から生まれる。
フレームワークの価値を、便利な機能一覧として説明すると弱くなります。 BEAR.Sundayでは、技術的特徴がアプリケーションの形を決め、その形が開発、運用、利用体験に 直接つながります。制約があるから、コードの意味が残り、変更の影響を追えます。
Read Modelが、Webの仕組みに乗る
本質的に静的なリソース表現を生成し、ETag、304、依存タグ、CDN purgeへ接続します。単なるキャッシュではなく、アプリケーションの読み取りモデルをWebインフラ上に創り出す設計です。
変更は、外側から差し替える
Guice由来のModule、Binding、ProviderとAOPにより、環境差分、表現形式、横断的関心をリソースの中へ混ぜません。振る舞いの変更は束縛やInterceptorへ寄せられ、ビジネスロジックの輪郭が残ります。
Value chain
設計上の選択が、利用者の体験まで届く。
BEAR.Sundayでは、内部の設計原則と外部のWebインフラが分断されません。 リソースの意味、依存関係、表現の同一性がつながるため、開発しやすさと配信品質が同じ線上にあります。
- 01Resourceとして意味を表す
- 02Ray.DiのModuleで依存を宣言する
- 03Injectorがobject graphを生成する
- 04AOPで横断的関心を付与する
- 05Read Modelとして表現を生成する
- 06CDN、ETag、304へ接続する
- 07速さ、保守性、継続性として返る
Who benefits
開発者、ユーザー、ビジネスに、別々ではなく同じ構造から価値が届く。
開発者にとって
コアのロジックに集中できる。
BEAR.Sundayは便利な部品を大量に抱えるのではなく、変わりにくい制約を提供します。ResourceObjectはアプリケーションの意味を表し、依存はRay.DiのKeyとProviderから入り、表現やキャッシュは外側で扱われます。開発者はAPP_DEBUGのような実行モード分岐やサービスロケータを追う必要がなく、リソースの責務に集中できます。
- URI、onGet / onPost、Link、Embedから機能の境界を追える
- Ray.DiとROAにより、テスト対象を小さく保てる
- ライブラリ非同梱方針により、標準部品を選んで交換できる
チームにとって
疎結合のまま、構造を共有できる。
個人の流儀でコードを増やすのではなく、Resource、Module、Interceptor、Rendererという共通の置き場所が決まります。複数の開発者やAIエージェントが同じ地図で変更でき、レビューでは「この処理はどこに置くべきか」を具体的に議論できます。
- 依存方向がDIPとADPで揃うため、変更の影響を局所化しやすい
- context moduleが環境差分を集約し、実装内の条件分岐を減らす
- ドキュメント、スキーマ、llms.txtが実装の意味モデルにつながる
ユーザーにとって
速く、安定して、同じ機能に届く。
ユーザー価値は、フレームワーク名ではなく体験に現れます。本質的に静的なコンテンツはCDNから配信され、変更がなければETagで304になります。オリジンやDBに到達しないリクエストが増えるほど、レスポンスは速くなり、障害時にも読める範囲が広がります。
- CDN中心のRead Modelにより、応答速度と可用性が上がる
- 依存解決により、古い表現や古いETagを残しにくい
- 同じリソースをWeb、API、CLIへ接続できる
ビジネスにとって
継続コストを下げ、変化に耐える。
短期の開発速度だけでなく、運用後に変更し続けられることが価値になります。BEAR.Sundayは後方互換性を重視し、標準技術へ接続し、キャッシュをアーキテクチャに織り込みます。機能追加、表現変更、アプリ統合をHTTPの壁で分断せず、namespaceとDI bindingで扱えることは、組織の成長に効きます。
- Eternal 1.xの方針が、移行コストと技術的断絶を抑える
- CDNと304の活用が、インフラ負荷と障害影響を下げる
- 複数アプリケーションをHTTP境界なしに統合できる
開発者には、変更しやすく読める構造を。ユーザーには、速く安定した体験を。 ビジネスには、移行と運用のコストを抑えながら成長できる土台を。 その3つは別々の機能ではなく、Resource、DI、AOP、CDN中心のRead Modelという同じ設計から生まれます。
Start with one resource