BEAR.Sunday — リソース指向 PHP アプリケーションフレームワーク

Kimi K3生成によるBEAR.Sundayスライド

Transcript

1. PHP · RESOURCE-ORIENTED FRAMEWORK BEAR.Sunday リソース指向アーキテクチャ（ROA）の PHP フレームワーク クリーンなオブジェクト指向設計と REST の原則を組み合わせ、Web の根本原則を アプリケーション全体の制約にする。 Everything is a Resource. Ray.Di 依存性注入 Ray.Aop アスペクト指向 BEAR.Resource REST リソース 公式ドキュメントに基づく技術紹介 · 2026-08
2. 0 1 · フ レ ームワ ー ク 概 要 BEAR.Sunday とは 3 つの小さな専門フレームワークを土台に、データとビジネスロジックを「リソース」として統一する PHP アプリケーションフレー ムワーク。アプリ全体に及ぶ制約が、長期的な品質と一貫性をもたらします。 Ray.Di Ray.Aop BEAR.Resource 依存性注入（DI） アスペクト指向（AOP） REST リソース 依存関係逆転の原則でオブジェクトの依存をイ 本質的関心と横断的関心をアスペクト指向で接 REST 制約でアプリのデータと機能を、リンク ンターフェース化。Google Guice の設計思想を 続。Java AOP Alliance に準拠。 可能で操作可能なリソースとして接続。 採用。 “ フレームワークは残り、ライブラリは変わる。BEAR.Sunday は認証や DB といった専用ライブラリを内蔵せず、良質なサードパーティ 製ライブラリを選ぶ権利と責任をアプリケーションアーキテクトに委ねます。フレームワークはあくまでアプリケーションの制約として 存在します。 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 02 / 17
3. 02 · 設計思想 長期メンテナンスのための設計 01 Eternal 1.x —— 後方互換を決して壊さない 2015 年の初版以来、後方互換性を壊す変更を一度も導入せず進化を続けています。古くなったコードは deprecated 属性を付けるだけで削除 せず、新機能は常に「追加」の形で導入。互換性修正や回帰テストが不要になり、技術的負債が将来に持ち越されません。 02 標準を採用し、独自ルールを排する HTTP・JsonSchema・HAL・vnd.error+json などの標準技術を積極採用。DI は Google Guice、AOP は Java AOP Alliance に準拠し、フレー ムワーク固有のバリデーションルールや独自規約を可能な限り排除しています。 03 制約は自由をもたらす DI・AOP・REST が課す一貫した制約は時間を経ても変わらず、開発者を一貫した設計・実装に導き、アプリケーションの品質を長期的に高 めます。継承より合成、すべては注入——創造性はアプリケーション側に残されます。 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 03 / 17
4. 03 · アーキテクチャ リソース指向アーキテクチャ：Everything is a Resource URI アプリ内のすべてのリソースに URI を付与。URI は識別子であると同時 ResourceObject Renderer（注入） に、リソース間のリンクを表現します。 onGet / onPost / onPut… リソース状態を リソース状態のみを設定 状態表現に変換 統一インターフェース code · headers · body GET / POST / PUT / PATCH / DELETE / OPTIONS でリソースを操作。リ ソースの種類によらない共通インターフェースです。 ハイパーメディア JSON 各リソースはハイパーリンクで affordance（利用可能な操作）を提示し、 HTML クライアントをアプリ内で導きます。 コードは同一のまま、コンテキストで Renderer の束縛を切り替えるとリソースの表現 状態と表現の分離 形式が変わります。 リソースクラスは状態のみを管理。注入された Renderer が状態を JSON・HTML などの表現に変換し、ドメインロジックと表現ロジックを 疎結合に保ちます。 ROA は通常 REST API 設計に使われますが、BEAR.Sunday はそれを Web アプリケ ーション全体に拡張しています。 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 04 / 17
5. 03 · アーキテクチャ 従来の MVC との違い 観点 リクエスト処理 入力の取得 従来の MVC BEAR.Sunday の ROA コントローラがリクエストオブジェクトを受け取り、一連の処理 リソースは単一責任の原則に従い、リクエストメソッドで自身の状態 を制御してレスポンスを返す を宣言するだけ。表現には関与しない コントローラがリクエストオブジェクトから手動で値を取り出す 必要な変数をメソッド引数として宣言的に定義し、JsonSchema で検 証・文書化 リソース間の関係 コントローラとモデルの関係に制約がない リソース同士は URI とハイパーリンクで明示的に合成。包含関係や木 構造を宣言的に定義し情報隠蔽を保つ 外部アクセス モデルやコントローラは HTTP 経由で直接アクセスできない すべてのリソースに HTTP で直接アクセスできる 制約が増えるほど自由度は上がる——一貫したインターフェースがリソースをテスト可能・リンク可能・キャッシュ可能にします。 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 05 / 17
6. 03 · アーキテクチャ 実行メカニズム：コンパイル → リクエスト → レスポンス 0 Compile コンパイル 1 Request リクエスト 2 Response レスポンス コンテキストに応じて DI / AOP でアプリケ HTTP リクエストがルータでリソースリク ーションオブジェクト $app を構築 エストに変換される router · resource · transfer をオブジェクト onGet / onPost がリソース状態を設定 される グラフとして接続 #[Embed] / #[Link] で他リソースを合成可能 Transfer が表現をクライアントへ シリアライズされ、各リクエストで再利用 される メソッドの前後で AOP によるログ・認証な リソースに Renderer を注入 状態が HTML / JSON などに表現 転送 どを実行 リソースのメソッドは状態だけに関心を持ち、表現には関与しません。AOP のアスペクトも自分が束縛されていることを知らない——各層はインターフェ ースにのみ依存し、完全に分離されています。 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 06 / 17
7. 04 · 依存性注入 Ray.Di：コンパイル時に解決する DI Guice の系譜 Google Guice の設計思想を採用し、その機能のほぼすべてを モジュール内の束縛 DSL カバー // クラス束縛 コンパイル時解決 依存解決はコンパイル時に完了。実行時のコンテナ参照が なく、実行時解決型の DI コンテナより高速 $this->bind($iface)->to($class); // ファクトリ / インスタンス束縛 $this->bind($iface)->toProvider($prov); コンテキスト束縛 束縛をコンテキストで切り替え、テスト時に別実装を注入 可能 $this->bind($iface)->toInstance($obj); // 名前付き束縛とシングルトン $this->bind($iface) ->annotatedWith($anno) Attribute 設定 PHP Attribute による設定でコードの自己記述性を向上 ->to($class); $this->bind($iface)->to($class) 可視化 オブジェクトの依存関係をグラフとして可視化できる ->in(Scope::SINGLETON); 依存は責務ごとに横方向へ分割され、さらに縦方向の依存ツリーを形成。そ れぞれ独立して開発・テストできます。 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 07 / 17
8. 0 4 · ア スペ ク ト 指 向 Ray.Aop：横断的関心の分離 関心の分離 ビジネスロジックと、ログ・キャッシュ・トランザクション・セ キュリティなどの横断的関心を分離 インターセプタ：メソッド呼び出しの前と後 class MyInterceptor 宣言的な束縛 implements MethodInterceptor PHP Attribute でインターセプタをクラスとメソッドに束縛。 { Java AOP Alliance に準拠 public function invoke( MethodInvocation $invocation Matcher による探索 条件に合うクラスとメソッドを「検索」して束縛。コ ){ // メソッド呼び出しの前 … ンテキストで柔軟に切り替え可能 $result = $invocation->proceed(); 横断的な制約 // メソッド呼び出しの後 … AOP は秩序を破る特権ではなく、アプリケーションに横断的 return $result; な制約を確立するパラダイム } } 組み込み Matcher インターセプタはメソッド・引数・インスタンスを検査し、横断的ロジックを any · annotatedWith · subclassesOf · startsWith · logicalOr · logicalAnd · logicalNot 実行してから元のメソッドに委譲。1 つのインターセプタを多数のメソッドに 適用できます。 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 08 / 17
9. 0 4 · コ ン テ キス ト コンテキスト文字列：グローバルなモード定数は存在しない コンテキスト文字列（例） prod-hal-api-app モジュールのインストール順（右から左へ解析。後にインストールされたモジュールが先の束縛を上書き可能） AppModule ApiModule 振る舞いはコンテキストが決める コンパイル時にのみ存在 HalModule ProdModule ← 最も優先度が高い 各セグメントが DI モジュールに対応し、環境に応じた if 分岐ではなく束縛の組み合わせがアプリの振る舞いを決定 コンテキストはオブジェクトグラフの構築にのみ使われ、アプリケーションコードは自分がどのコンテキストで動いているかを 知る術も必要もない APP_DEBUG / APP_MODE は存在しない 組み込みコンテキスト 振る舞いの変更 ＝ インターフェースから実装への束縛の変更。コード自体は変えない api · cli · hal · prod は組み合わせ可能。src/Module/ に同名モジュールを置けばカスタムが優先される 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 09 / 17
10. 05 · パフォーマンスとスケーラビリティ イベント駆動の CDN 分散キャッシュ クライアント CDN エッジキャッシュ（Fastly 等） オリジン BEAR.Sunday リソース変更イベント → 即時パージ + ETag 更新 変更がなければ ETag で素早く同一性を確認し、304 Not Modified を返してネットワーク負荷を最小化 TTL を超えて セマンティックな無効化 生存時間に頼らず、リソース状態の変更イベントで CDN とサーバー側のキ GET / PUT などのメソッドに意味的な役割を持たせ、依存リソース ャッシュを即時無効化 のキャッシュを協調的に無効化。一貫性と鮮度を保証 Donut Caching + ESI 高い障害耐性 CDN エッジで部分的に更新。ページ全体を再キャッシュせず必要な部分 コンテンツは CDN に永続保存。PHP や DB がダウンしてもサービ だけ動的に刷新 スは継続し、単一障害点を排除 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 10 / 17
11. 05 · パフォーマンスとスケーラビリティ 実行時最適化と透過的並列実行 実行時最適化 コンパイル時 DI 透過的並列実行 依存解決はコンパイル時に完了し、実行時のコンテナ 参照はゼロ 単一ルートオブジェクト アプリ全体が 1 つのルートオブジェクト変数 コンパイル済み依存グラフと opcache で高速ブートストラッ プ Swoole app://self/user は「ユーザー情報が欲しい」とい う意図だけを表し、MySQL か Redis かはアプリから隠蔽 として生成され、リクエスト間で再利用 php-fpm URI は意図を表す What / How の分離 #[Embed] で埋め込まれた複数リソースを並列取 得。アプリコードの変更は不要 3 段階の選択肢 ext-parallel（スレッドプール）/ Swoole（コルーチ ン）/ mysqli（DB クエリのみ） 永続ワーカーによりブートは初回の一度だけ。コルーチンコン テキストによるリクエスト分離で、スーパーグローバルに頼らず安全に並 行処理 標準的な PHP で開発・デバッグし、本番では設定変更だけで並列実行に切 り替え——10 年前に書いたリソースクラスも、モジュールを追加するだけで 並列化の恩恵を受けられます。 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 11 / 17
12. 06 · 接続性 1 つのリソース、多彩なアクセス方法 一度作ったリソースは、コードを変えずに Web・コンソール・他アプリ・他言語からアクセスできます。 HTTP クライアント MVC のモデルやコントローラと異なり、すべてのリソースに HTTP で直接アクセスできます。 コンソールアクセス ソースコードを変えずにコンソールからリソースへ直接アクセス。同一リソースを Web とコマンドラインの両方 で利用。 BEAR.CLI リソースを独立した UNIX コマンドとして配布し、Homebrew 経由でインストール可能に。 Composer パッケージ vendor ディレクトリの他の BEAR.Sunday アプリのリソースを直接呼び出し。マイクロサービスなしで複数アプ リが連携。 BEAR.Thrift 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 他言語・他の PHP バージョンと効率的に相互運用。異なる PHP バージョンの共存も可能です。 12 / 17
13. 07 · 開発者体験 開発者体験：テストしやすく、自己文書化され、観測できる なぜテストしやすいのか アプリケーションがドキュメントになる ステートレスなリソース コードから ApiDoc HTML・OpenAPI 3.1・JSON Schema・llms.txt 各リソースは独立しており、REST リクエストは無状 態。隔離したテストが書きやすい を自動生成。ALPS プロファイルを SSOT（信頼できる唯一の情報 源）とすれば、同じ文書が開発者・アーキテクト・AI それぞれに届 状態を直接検証 状態と表現が分離しているため、HTML 表現のリソースでも状 態を直接アサートできる ハイパーメディアテスト きます。 可視化とデバッグ リンクをたどる API テストが可能。PHP と HTTP で 同じテストコードを共有 開発中は HTML 上でリソースの範囲を表示し、状態をモニタリン グ。PHP コードとテンプレートをオンラインエディタで編集して即 時反映できます。 コンテキスト注入 テスト用コンテキストで別実装を束縛。コードを変えずにテ ストダブルを注入 セキュリティ分析に適した構造 エンドポイントは ResourceObject、入力は JsonSchema で宣言、依 存はコンストラクタ注入で明示。隠れた魔法がないため、SAST / DAST / 汚染解析 / AI 監査が完全なデータフローを追跡できます。 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 13 / 17
14. 08 · 品質と互換性 コード品質と互換性の約束 非循環依存の原則（ADP）：依存は一方向で循環しない。各層は上位の存在を知らない ray/aop ray/di bear/resource bear/sunday bear/package 各パッケージは独立して更新可能。システム全体をロックするバージョン番号も、オブジェクト間に横断依存を持つプロキシ機構も存在しません コード品質の基準 互換性の約束 テストカバレッジ 100%、型カバレッジはほぼ 100% セマンティックバージョニング（Semver）に準拠し、破壊的なメジ Psalm と PHPStan の最も厳しいレベルで静的解析を適用 本質的にイミュータブルなシステムで、テストのたびの初期化も不要。 Swoole などの非同期エンジンの力を解放します ャーアップグレードは行わない composer update はいつでも実行可能。マイナーアップグレードで アプリコードの変更は不要 PHP のメジャーアップグレード（例：5.6 → 7.0）でも、アプリケー ションコードの互換性は壊れない 現在のサポート対象は PHP 8.1 – 8.4（8.4 が現在の安定版） 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 14 / 17
15. 09 · クイックスタート 3 ステップで最初のリソースを作る 1 Composer でプロジェクトスケルトンを作成 VENDOR=MyVendor PACKAGE=MyProject composer create-project bear/skeleton my-project 2 ページリソース src/Resource/Page/Hello.php を作成 class Hello extends ResourceObject { public function onGet(string $name = 'BEAR.Sunday'): static { $this->body = ['greeting' => 'Hello ' . $name]; return $this; } } 3 コンソールと Web の両方から同じリソースにアクセス php bin/page.php get '/hello?name=World' 200 OK · application/hal+json php -S 127.0.0.1:8080 -t public { "greeting": "Hello World", curl -i 127.0.0.1:8080/hello "_links": { "self": { "href": "/hello?name=World" } } } 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 15 / 17
16. 10 · 価値 変わらない制約がもたらす、3 者への価値 開発者にとって ユーザーにとって ビジネスにとって 時間を経ても変わらない堅牢な制約で、コアなビ 実行時最適化と CDN キャッシュ戦略による、高 一貫した構造が持続可能な開発プロセスを促進し、 ジネスロジックに集中できる 速でレスポンシブな体験 開発コストを削減 一貫したガイドラインと構造で、チームのコード 単一障害点を最小化し、安定したサービスを享受 後方互換の維持が技術的継続性を高め、保守コスト は疎結合かつ統一される できる を削減 ライブラリを内蔵しない方針が、コンポーネント 優れた接続性で、他言語・他システムとの連携が DI / AOP で最小限のコード変更のままビジネスの成 選定の柔軟さと自由をもたらす 容易 長に拡張できる DI + ROA でテストが書きやすい 高いパフォーマンスと可用性が満足度とロイヤルテ ィを向上 「優れた制約は変わらない。」—— BEAR.Sunday 公式ドキュメント 出典：BEAR.Sunday 公式ドキュメント（2026-08-07 参照） 16 / 17
17. Everything is a Resource. Web の原則と精神に基づき、明確な制約で柔軟かつ堅牢なアプリケーションを構築する。 リ ソ ース と リ ン ク 公式ドキュメント・マニュアル フレームワークリポジトリ DI / AOP bearsunday.github.io github.com/bearsunday/BEAR.Sunday ray-di/Ray.Di · ray-di/Ray.Aop AI 可読ドキュメント bearsunday.github.io/llms-full.txt 本プレゼンテーションは BEAR.Sunday 公式ドキュメント（llms-full.txt）に基づき作成 · 2026-08-07 参照 · 技術紹介目的