content clarity and readability

This update improves the clarity and readability of certain sections in the tech manual. Redundant and overly complex sentences were simplified, resulting in a more streamlined and coherent document.

manuals/1.0/ja/15.tech.md

@@ -11,8 +11,6 @@ permalink: /manuals/1.0/ja/tech.html
 
 ### リソース指向アーキテクチャ (ROA)
 
-> "Resources interconnected, like the web of life that binds all creatures.”
-
 BEAR.Sunday のROAは、Web アプリケーション内でRESTful APIを実現するアーキテクチャです。これはBEAR.Sundayの設計原則の核となるものであり、ハイパーメディアフレームワークであると同時に"サービスしてのオブジェクト(Object as as service)"をとして扱います。Webと同様に、全てのデータや機能をリソースとみなし、GET、POST、PUT、DELETEなどの標準化されたインターフェースを通じて操作します。
 
 #### URI
@@ -27,34 +25,20 @@ URI（Uniform Resource Identifier）はWebの成功の鍵となる要素であ
 
 BEAR.Sunday のリソース指向アーキテクチャ (ROA) では、各リソースがハイパーリンクを通じてアフォーダンス（クライアントが利用可能な操作や機能）を提供します。これらのリンクは、クライアントが利用できる操作を表し、アプリケーション内をナビゲートする方法を指示します。
 
-ハイパーリンクはリソース間の関係を示すだけでなく、リソースを埋め込むメカニズムとしても機能します。これはHTMLでIMGタグを用いて画像を埋め込む方法に類似しています。
-
-BEAR.Sundayでは、内部リンクを通じてリソース間の関係を宣言的に構築し、コンテンツのツリー構造を形成します。
-
 #### 値と表現の分離
 
-BEAR.SundayのROAでは、リソースの値と表現が明確に分離されています。リソースの値はアプリケーションのドメインロジックによって管理され、表現はその値を様々な形式（JSON, XML, HTMLなど）で表現するためのものです。この分離によってドメインロジックとプレゼンテーションロジックが疎結合になり、アプリケーションの保守性と拡張性が向上します。
-
-#### pageリソースとappリソース
-
-BEAR.SundayのROAでは、リソースはpageリソースとappリソースの二つに分類されます。
-
-- pageリソース: 主にHTMLを表現とするリソースで、Webブラウザからアクセスされることを想定しています。ユーザーインターフェースを構成するリソースです。
-- appリソース: アプリケーションのバックエンドを構成するリソースで、主にJSONやXMLを表現とします。他のアプリケーションやサービスからアクセスされることを想定しています。
+BEAR.SundayのROAでは、リソースの値と表現が明確に分離されています。リソースの値はアプリケーションのドメインロジックによって管理され、表現はその値を様々な形式（JSON, XML, HTMLなど）で表現するためのものです。この分離によってドメインロジックとプレゼンテーションロジックが疎結合になります。
 
 #### MVCとの相違点
 
-BEAR.SundayのROAは、従来のMVCアーキテクチャとは異なるアプローチをとっています。MVCはモデル、ビュー、コントローラーの3つのコンポーネントでアプリケーションを構成しますが、BEAR.Sundayでは、リソースオブジェクトにビューがインジェクトされます。リソースとビューは疎結合であり、それぞれの責務が明確に分離されています。
+BEAR.SundayのROAは、従来のMVCアーキテクチャとは異なるアプローチをとっています。MVCはモデル、ビュー、コントローラーの3つのコンポーネントでアプリケーションを構成します。一方、BEAR.Sundayでは、リソースオブジェクトにビューがインジェクトされます。リソースとビューは疎結合で、それぞれの責務が明確に分離されています。
 
-また、コントローラーとモデルの関係に制約がないのと対照的に、リソースは他のリソースを含むことにURIを用いた制約があり、宣言的に行うことができます。 その他以下のような違いがあります。
+また、コントローラーとモデルの関係に制約がないのと対照的に、リソースは他のリソースを含むことにハイパーリンクとURIを用いた制約があり、宣言的に行うことができます。
 
-- MVCのモデルと違って、コンソールを含む多様なクライアントから直接コールすることができます。
-- HTMLサイトとAPIサイトを別々に構築する必要がなく、同じリソースを使ってHTMLサイトとAPIサイトを同時に構築できます。
+MVCのモデルと違って、コンソールを含む多様なクライアントから直接コールすることができますし、 そのめHTMLサイトとAPIサイトを別々に構築する必要がなく、同じリソースを使ってHTMLサイトとAPIサイトを同時に構築できるといった違いがあります。
 
 ### 依存性の注入 (DI)
 
-> "Objects are injected from the interface, just as sun ray is injected when a window is opened."
-
 依存性の注入 (Dependency Injection, DI) は、オブジェクト指向プログラミングにおけるアプリケーションの設計と構造を強化するための重要な手法です。DIの中心的な目的は、アプリケーションの機能を複数の独立したドメインまたは役割を持つコンポーネントに分割し、それらの間の依存関係を管理することです。
 
 DIは、1つの機能を複数の機能に水平分割するのに役立ちます。分割された機能は「依存」として各部分を独立して開発、テストができるようになります。単一責任原則に基づき明確な責任と役割を持つそれらの依存を外部から注入することで、オブジェクトの再利用性とテスト性を向上させます。また依存は他の依存へと垂直でも分割され、依存関係のツリーを形成します。
@@ -65,49 +49,40 @@ BEAR.SundayのDIは[Ray.Di](https://github.com/ray-di/Ray.Di)という独立し
 
 * コンテキストにより束縛を変え、テスト時に異なる実装を注入することができます。
 * アトリビュートによる設定でコードの自己記述性が高まります。
-* 同じインターフェイスで違う実装を束縛するためのクオリファイアーを使うことでもコードの自己記述性が高まります。
 * Ray.Diはコンパイル時に依存性の解決を行うため、ランタイム時のパフォーマンスが向上します。これは、実行時に依存性を解決する他のDIコンテナとは異なる点です。
 * オブジェクトの依存関係をグラフで可視化できます。例）[アプリケーションスケルトン](/images/app.svg)
-* インスタンス化のためのコストが大きい依存は、遅延束縛して実行時にインスタンスを得ることもできます。
 
 <img src="https://ray-di.github.io/images/logo.svg" width="180" alt="Ray.Di logo">
 
 ### アスペクト指向プログラミング (AOP)
 
-> "Aspects wrap your objects, like a gift wrap enhances a present."
-
-アスペクト指向プログラミング(AOP)は、ビジネスロジックなどの本質的な関心と、ログやキャッシュなどの横断的関心を分離することで、柔軟なアプリケーションを実現するパターンです。横断的関心とは、複数のモジュールやレイヤーにまたがって存在する機能や処理のことを指します。
+アスペクト指向プログラミング(AOP)は、ビジネスロジックなどの本質的な関心と、ログやキャッシュなどの横断的関心を分離することで、柔軟なアプリケーションを実現するパターンです。横断的関心とは、複数のモジュールやレイヤーにまたがって存在する機能や処理のことを指します。探索条件に基づいた横断的処理の束縛が可能で、コンテキストに基づいた柔軟な構成が可能です。
 
 BEAR.SundayのAOPはRay.Aopという独立したパッケージを使用しており、PHPのアトリビュートをクラスやメソッドに付与して、横断的処理を宣言的に束縛します。Ray.Aopは、Javaの[AOP Alliance](https://aopalliance.sourceforge.net/)に準拠していて、以下のような特徴を持っています。
 
-* アトリビュートを使用した宣言的な記述方法により、コードの可読性が向上します。
-* 探索条件に基づいた横断的処理の束縛が可能で、コンテキストに基づいた柔軟な構成が可能です。
-
-AOPは誤解の多い技術の一つです。その存在意義は強力な力のために制約を無視して秩序を壊すものではなく、探索的な機能の割り当てや横断的処理の分離などオブジェクト指向が不得意とする分野を補完し、アプリケーション横断的な制約を作る、つまりアプリケーションフレームワークの制約として設計が可能なパラダイムの1つです。
+AOPは誤解の多い技術の一つです。その存在意義は強力な力のために秩序を壊すものでは決してなく、マッチャーを使った探索的な機能の割り当てや横断的処理の分離などオブジェクト指向が不得意とする分野を補完します。AOPはアプリケーションの横断的な制約を作る、つまりアプリケーションフレームワークとして機能するパラダイムです。
 
 ## パフォーマンスとスケーラビリティ
 
 ### モダンCDNとの統合によるROAベースのイベントドリブンコンテンツ戦略
 
-> "No volatility, just what users truly desire."
-
 BEAR.Sundayは、リソース指向アーキテクチャ（ROA）を中核として、Fastlyなどのインスタントパージ可能なCDNと統合することで、高度なイベントドリブンキャッシュ戦略を実現しています。この戦略では、従来のTTL（Time to Live）によるキャッシュの無効化ではなく、リソースの状態変更イベントに応じてCDNとサーバーサイドのキャッシュ、およびETag（Entity Tag）を即座に無効化します。
 
-揮発性を排除したこのアプローチは、SPOF（Single Point of Failure）を回避し、高い可用性と耐障害性を実現するだけでなく、ユーザー体験とコスト効率を最大化させ、ダイナミックコンテンツでもスタティックコンテンツと同じWeb本来の分散キャッシングを実現します。つまり、Webが1990年代から持っていたスケーラブルでネットワークコストも削減する分散キャッシュという原則を、現代的な技術で再実現しているのです。
+揮発性を排除したこのアプローチは、SPOF（Single Point of Failure）を回避し、高い可用性と耐障害性を実現するだけでなく、ユーザー体験とコスト効率を最大化させ、ダイナミックコンテンツでもスタティックコンテンツと同じWeb本来の分散キャッシングを実現します。Webが1990年代から持っていたスケーラブルでネットワークコストも削減する分散キャッシュという原則を、現代的な技術で再実現しているのです。
 
 #### セマンティックメソッドと依存によるキャッシュ無効化
 
 BEAR.SundayのROAでは、各リソース操作にセマンティック（意味的な役割）が与えられています。例えば、GET メソッドはリソースを取得し、PUT メソッドはリソースを更新します。これらのメソッドがイベントドリブン方式で連携し、関連するキャッシュを効率的に無効化します。たとえば、特定のリソースが更新された際には、そのリソースを必要とするリソースのキャッシュが無効化されます。これにより、データの一貫性と新鮮さが保たれ、ユーザーに最新の情報が提供されます。
 
 #### ETagによる同一性確認と迅速な応答
 
-システムがブートする前にETagを設定することで、コンテンツの同一性を迅速に確認し、変更がなければ304 Not Modified応答を返します。これはネットワークの負荷を減少させ、ユーザーエクスペリエンスを向上させるための効果的な手法です。
+システムがブートする前にETagを設定することで、コンテンツの同一性を迅速に確認し、変更がなければ304 Not Modified応答を返しネットワークの負荷を最小化します。
 
 #### ドーナッツキャッシュとESIによる部分的な更新
 
-BEAR.Sundayでは、ドーナッツキャッシュ戦略を採用しており、ESI(Edge Side Includes)を使用してCDNエッジで部分的なコンテンツ更新を可能にしています。この技術により、ページ全体を再キャッシュすることなく、必要な部分だけを動的に更新でき、パフォーマンスとキャッシュの効率を大幅に向上させています。
+BEAR.Sundayでは、ドーナッツキャッシュ戦略を採用しており、ESI(Edge Side Includes)を使用してCDNエッジで部分的なコンテンツ更新を可能にしています。この技術により、ページ全体を再キャッシュすることなく、必要な部分だけを動的に更新しキャッシュ効率を向上させます。
 
-このように、BEAR.SundayとFastlyの統合によるROAベースのキャッシュ戦略は、高度な分散キャッシングの実現とともに、アプリケーションのパフォーマンス向上と耐障害性の強化を実現しています。これにより、ユーザーはどんな状況下でも一貫した応答性とデータ整合性を体験することができます。
+このように、BEAR.SundayとFastlyの統合によるROAベースのキャッシュ戦略は、高度な分散キャッシングの実現とともに、アプリケーションのパフォーマンス向上と耐障害性の強化を実現しています。
 
 ### 起動の高速化
 
@@ -200,23 +175,23 @@ BEAR.Sunday では、セマンティックバージョニングを採用する
 
 ### 開発者にとっての価値
 
-- 生産性の向上：堅牢な設計パターンと原則に基づき時間による変更にない制約で、開発者はコアなビジネスロジックに集中できソフトウエアを資産として開発を継続することができます。
+- 生産性の向上：堅牢な設計パターンと原則に基づき時間による変更にない制約で、開発者はコアなビジネスロジックに集中できます。
 - チームでの協業：開発チームに一貫性のあるガイドラインと構造を提供することで、異なるエンジニアたちのコードを疎結合のまま統一的に保ち、コードの可読性とメンテナンス性を向上します。
-- 柔軟性と拡張性：BEAR.Sundayのライブラリを含まない方針は、開発者にコンポーネントの選択における柔軟性と自由をもたらし、将来の変化にも対応できます。
+- 柔軟性と拡張性：BEAR.Sundayのライブラリを含まない方針は、開発者にコンポーネントの選択における柔軟性と自由をもたらします。
 - テスト容易性:BEAR.Sunday の DI（依存性の注入）と ROA（リソース指向アーキテクチャ）がテスト容易性を高めます。
 
 ### ユーザーにとっての価値
 
-- 高いパフォーマンス：BEAR.Sundayの最適化された高速起動とCDN（コンテンツ配信ネットワーク）を中心としたキャッシュ戦略は理論上最高のパフォーマンスをもたらし、ユーザーは高速で応答性の高いエクスペリエンスを享受できます。
-- 信頼性と可用性：BEAR.SundayのCDNを中心としたキャッシュ戦略は、単一障害点（SPOF）を最小化し、PHPやDBサーバーがダウンしてもサービス提供を続けるほどの信頼性と可用性を実現させます。ユーザーはダウンしない安定したサービスを享受できます。
+- 高いパフォーマンス：BEAR.Sundayの最適化された高速起動とCDN（コンテンツ配信ネットワーク）を中心としたキャッシュ戦略はユーザーに高速で応答性の高いエクスペリエンスをもたらします。
+- 信頼性と可用性：BEAR.SundayのCDNを中心としたキャッシュ戦略は、単一障害点（SPOF）を最小化し、ユーザーは安定したサービスを享受できます。
 - 使いやすさ：BEAR.Sundayの優れた接続性は他の言語やシステムと協調することを容易にします。
 
 ### ビジネスにとっての価値
 
 - 開発コストの削減：BEAR.Sundayが提供する一貫性のあるガイドラインと構造は、持続的で効率的な開発プロセスを促進し開発コストを削減します。
 - 維持コストの削減：BEAR.Sundayの後方互換性を維持するアプローチは、技術的継続性を高め、変更対応の時間とコストを最小限に抑えます。
 - 高い拡張性：BEAR.Sunday のコードの変更を最小限に抑えながら振る舞いを変えることができるDI（依存性の注入）やAOP（アスペクト指向プログラミング）といった技術で、ビジネスの成長や変化に合わせながらアプリケーションを容易に拡張できます。
-- 優れたユーザーエクスペリエンス(UX)：BEAR.Sunday は高いパフォーマンスと高い可用性を提供することで、ユーザーの満足度を高めます。優れたUXは、顧客ロイヤリティの向上、顧客基盤の拡大、ビジネスの成功に貢献します。
+- 優れたユーザーエクスペリエンス(UX)：BEAR.Sunday は高いパフォーマンスと高い可用性を提供することで、ユーザーの満足度を高め、顧客ロイヤリティの向上、顧客基盤の拡大、ビジネスの成功に貢献します。
 
 優れた制約は変わりません。BEAR.Sundayがもたらす制約は、開発者、ユーザー、ビジネスのそれぞれに具体的な価値を提供します。