From 4f30c204294b3acd1d02bece42adbded6f3ecec5 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 20 Mar 2026 11:24:23 +0900 Subject: [PATCH 1/5] Review and improve Japanese manual expressions across all chapters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Fix unnatural/stiff Japanese expressions and split overly long sentences - Unify "Beフレームワーク" to "Be Framework" across all files - Fix terminology: "一次市民" → "第一級市民" (first-class citizen) - Fix grammar: "コントローラーもオーケストレーターといった" → proper particle usage - Fix style inconsistency: remove first-person "私" in 03-being-classes.md - Improve technical accuracy: "#[Validate]メソッド" → "#[Validate]属性が付いたメソッド" - Rename section "名前の装飾" → "属性による制約の拡張" in 06-semantic-variables.md - Remove Sartre reference in 12-philosophy-behind.md (contradicts framework's position) Co-Authored-By: Claude Opus 4.6 (1M context) --- manuals/1.0/ja/01-overview.md | 16 ++++++++-------- manuals/1.0/ja/02-input-classes.md | 6 +++--- manuals/1.0/ja/03-being-classes.md | 14 ++++++++------ manuals/1.0/ja/04-final-objects.md | 4 ++-- manuals/1.0/ja/04a-becoming.md | 4 ++-- manuals/1.0/ja/05-metamorphosis-patterns.md | 10 +++++----- manuals/1.0/ja/06-semantic-variables.md | 8 ++++---- manuals/1.0/ja/08-reason-layer.md | 6 +++--- manuals/1.0/ja/09-error-handling.md | 4 ++-- manuals/1.0/ja/10-semantic-logging.md | 2 +- manuals/1.0/ja/12-philosophy-behind.md | 6 ++---- manuals/1.0/ja/13-vision-ldd.md | 4 ++-- manuals/1.0/ja/14-faq.md | 8 ++++---- manuals/1.0/ja/demos.md | 2 +- manuals/1.0/ja/getting-started.md | 2 +- manuals/1.0/ja/index.md | 12 ++++++------ manuals/1.0/ja/tutorial.md | 4 ++-- 17 files changed, 56 insertions(+), 56 deletions(-) diff --git a/manuals/1.0/ja/01-overview.md b/manuals/1.0/ja/01-overview.md index 61a0f0a..b3b52a4 100644 --- a/manuals/1.0/ja/01-overview.md +++ b/manuals/1.0/ja/01-overview.md @@ -36,7 +36,7 @@ $user->save(); $user->notify(); ``` -BeフレームワークはBEING（何であるか）に着目します： +Be FrameworkはBEING（何であるか）に着目します： ```php $userInput = new UserInput($name, $email); $validatedUser = new ValidatedUser($userInput); @@ -63,27 +63,27 @@ BEINGに着目すると： // 従来型：汎用的な型 function processUser(User $user) { } -// Beフレームワーク：特定の存在状態 +// Be Framework：特定の存在状態 function processUser(ValidatedUser $user) { } function saveUser(SavedUser $user) { } function archiveUser(DeletedUser $user) { } ``` -各型はただのデータではなく、オブジェクトの特定の状態を表現しています。つまり、オブジェクトの時間的な変化が型で表されていて、その時に可能なことだけが行えます。例えば、存在しないオブジェクトに削除を命じることはできません。 +各型はただのデータではなく、オブジェクトの特定の状態を表しています。時間的な変化が型で表されるので、その時点で可能な操作だけが行えます。たとえば、削除済みのオブジェクトにさらに削除を命じることはできません。 ## なぜ「コントローラー」ではないのか？ -従来のMVCフレームワークにおける「コントローラー (Controller)」は、その名の通り「制御・支配」を目的としています。 しかし、システムが複雑になるにつれて、この「全てを支配しようとするアプローチ」は困難になります。 +従来のMVCフレームワークでは、コントローラーがアプリケーション全体の流れを制御します。しかし、システムが複雑になるにつれて、この「全てを制御しようとするアプローチ」は困難になります。 -コントローラーは全てのモデルやコンポーネントに無制限にアクセスできる「全能の自由」を持っていますが、制約がないということは、逆に言えばシステム内のあらゆる手続きについて、自分自身で制御し整合性を保つという「無限の責任」を負うことを意味します。 +コントローラーはあらゆるモデルやコンポーネントにアクセスできます。しかし制約がない分、すべての手続きの整合性を自分で保つ責任を負います。 -Be Frameworkは異なるアプローチを採ります。操作が目的のデータをつくり出すのではなく、種子のような単純な入力オブジェクトが他のオブジェクトと出会い、自然に成長し、目的の最終オブジェクトへと「自ら変容（Metamorphosis）」していきます。 +Be Frameworkは異なるアプローチを採ります。外部から操作してデータを組み立てるのではなく、シンプルな入力オブジェクトが自ら最終オブジェクトへと変容していきます。 ### Commander (司令官) から Gardener (庭師) へ: -* 司令官は、部下（オブジェクト）に「動け」と命令します。しかし、複雑な自律的な動きを全て命令し続けることは不可能です。 +* 司令官は部下（オブジェクト）に「動け」と命令します。しかし、システムが複雑になるほど、すべてを命令で制御し続けるのは困難です。 * 庭師は、植物に命令しません。ただ、水や光という環境を整えるだけです。 -植物は、自らの変容のみに関心を持ちます。他者を変えようとするのではなく、環境を受け入れて自らを自律的に変容（Metamorphosis）させ、在るべき姿に成ります。Beフレームワークも最初に入力を与えると、自らが最終オブジェクトになるような環境を整えます。制御を手放し、自律的な変容に委ねる。これがBe Frameworkのコアコンセプトです。 +植物は環境を受け入れ、自らの力で成長します。Be Frameworkのオブジェクトも同じです。入力を受け取ると、自ら最終オブジェクトへと変容していきます。制御を手放し、自律的な変容に委ねる。これがBe Frameworkのコアコンセプトです。 ## このマニュアルで学べること diff --git a/manuals/1.0/ja/02-input-classes.md b/manuals/1.0/ja/02-input-classes.md index 9826447..58002e3 100644 --- a/manuals/1.0/ja/02-input-classes.md +++ b/manuals/1.0/ja/02-input-classes.md @@ -13,9 +13,9 @@ permalink: /manuals/1.0/ja/02-input-classes.html ## 出発点 -入力クラスは、Beフレームワークにおけるすべての変容の出発点です。 +入力クラスは、Be Frameworkにおけるすべての変容の出発点です。 -ここにはオブジェクト自身が持つ要素だけが含まれ、外部依存がありません。いわばオブジェクトのアイデンティティです。オブジェクトの内側にあるものなので、これを**内在（Immanence）**と呼びます。 +入力クラスにはオブジェクト自身が持つ要素だけが含まれ、外部依存がありません。これがオブジェクトの本質的な属性です。オブジェクトの内側にあるものなので、これを**内在（Immanence）**と呼びます。 ## 基本構造 @@ -32,7 +32,7 @@ final readonly class UserInput ## 主要な特徴 -**純粋なアイデンティティ**: 入力クラスはオブジェクトが根本的に*何であるか*のみを含みます—外部依存関係や複雑なロジックはありません。 +**純粋なアイデンティティ**: 入力クラスはオブジェクトが*何であるか*だけを含みます。外部依存や複雑なロジックはありません。 **ユースケースの起点**: すべてのユースケースは固有の入力クラスを持ちます。 diff --git a/manuals/1.0/ja/03-being-classes.md b/manuals/1.0/ja/03-being-classes.md index 9eafe17..158c917 100644 --- a/manuals/1.0/ja/03-being-classes.md +++ b/manuals/1.0/ja/03-being-classes.md @@ -15,7 +15,9 @@ permalink: /manuals/1.0/ja/03-being-classes.html 入力クラスが「始まり」なら、存在クラスは「変容した存在」を表現します。 -入力クラスのpublicプロパティが存在クラスのコンストラクタに引き継がれます。その引き継いだ値は**内在（Immanence）** と呼ばれます。変容しながらアイデンティティを保ちます。コンストラクタでは外部から提供される力—**超越（Transcendence）**がインジェクトされ**内在**を変容します。 +入力クラスのpublicプロパティは、存在クラスのコンストラクタに引き継がれます。この引き継がれた値を**内在（Immanence）**と呼びます。内在はオブジェクトのアイデンティティであり、変容を経ても保たれます。 + +コンストラクタには外部から**超越（Transcendence）**もインジェクトされます。超越は内在と出会い、新しい内在へと変容させます。 ## 基本構造 @@ -39,7 +41,7 @@ final readonly class ValidatedUser ## 時間的存在としてのオブジェクト -Be Frameworkにおいて、オブジェクトは静的なデータ構造ではなく、特定の時間の中でのみ存在する時間的存在として扱われます。 +Be Frameworkでは、オブジェクトを静的なデータ構造ではなく、特定の時間の中でのみ存在する時間的な存在として捉えます。 ### 誕生 @@ -51,13 +53,13 @@ Be Frameworkにおいて、オブジェクトは静的なデータ構造では ### 生 -オブジェクトは `public readonly` プロパティとして、その「あるべき姿」を世界に晒します。しかしそのプロパティを触るものはいません。生まれた直後に次のオブジェクトのために消滅するからです。 +オブジェクトは `public readonly` プロパティとして、その「あるべき姿」を世界に晒します。しかし、そのプロパティが参照されることはありません。生まれた直後に、次のオブジェクトへ引き継がれて消滅するからです。 ### なりたい自分になる すべての変容は、最終的な「なりたい自分、なるべき自分（Final Object）」になるための旅です。 -出会った超越は、新しい内在に影響を与えて消滅します。幼少期の友人のように、私を形作り私の一部にはなりますが、その時だけの時間的存在として、もうそこにはいなくなります。 +出会った超越は、新しい内在に影響を与えて消滅します。幼少期の友人のように、オブジェクトを形作りその一部となりますが、その時だけの存在として、やがて消えていきます。 ## 変容の例 @@ -85,11 +87,11 @@ final readonly class OrderCalculation ## 変容についての考察 -内在だけでは変われません。データがどれほど豊かでも、それ自身の力で新しい存在にはなれないのです。変容には必ず超越—自分の外にある力—との出会いが必要です。そして出会った超越は内在を変え、自らは消えていきます。この「出会い、変わり、消える」というパターンは、コードに限った話ではありません。小麦粉はイーストと熱に出会ってパンになり、ぶどうは酵母と時間に出会ってワインになり、種は土と水と光に出会って花になります。あらゆるドメインの変容がこのパターンに従います。 +内在だけでは変われません。データがどれほど豊かでも、それ自身の力で新しい存在にはなれないのです。変容には必ず超越—自分の外にある力—との出会いが必要です。そして出会った超越は内在を変え、自らは消えていきます。この「出会い、変わり、消える」というパターンは、コードに限った話ではありません。小麦粉はイーストと熱に出会ってパンになります。ぶどうは酵母と時間に出会ってワインになります。種は土と水と光に出会って花になります。あらゆるドメインの変容がこのパターンに従います。 ## 自然な流れ -存在クラスは何かを「する」のではありません。自分が持つもの（内在）と、外部から与えられる力（超越）が出会うことで、自然にあるべき姿へと変容します。この流れを指揮するものはいません。各オブジェクトはただ次の存在に渡されるだけです。 +存在クラスは何かを「する」わけではありません。自分が持つもの（内在）と、外部から与えられる力（超越）が出会うことで、自然にあるべき姿へと変容します。この流れを指揮するものはいません。各オブジェクトはただ次の存在に渡されるだけです。 --- diff --git a/manuals/1.0/ja/04-final-objects.md b/manuals/1.0/ja/04-final-objects.md index 208f633..9aa55f8 100644 --- a/manuals/1.0/ja/04-final-objects.md +++ b/manuals/1.0/ja/04-final-objects.md @@ -50,7 +50,7 @@ final readonly class SuccessfulOrder } ``` -入力クラスとは対照的に、最終オブジェクトはドメインの豊かさを完全に表現した存在です。内在が超越と出会い、変容を経て、これ以上変わる必要のない完全な状態に達しています。成功も失敗も同じ構造です。`FailedOrder`も`BeenRejected`という`$been`を持ちます。 +入力クラスとは対照的に、最終オブジェクトはドメインの豊かさを完全に表現した存在です。内在が超越と出会い、変容を経て、これ以上変わる必要のない完全な状態に達しています。成功も失敗も同じ構造です。たとえば`FailedOrder`も、拒否の証跡として`$been`を持ちます。 ## 時間的存在の完全性 @@ -59,7 +59,7 @@ Be Frameworkでは、オブジェクトの時間的存在を二つの軸で捉 - **`#[Be]`**: なりたい自分、向かう先（未来への方向性） - **`$been`**: 完了した自分（過去完了の証跡） -`$orderId`や`$confirmationCode`といった本質的な値はpublicプロパティです。`$been`はそれとは異なり、いつ・誰が・何を根拠に完了したかという完了の証跡を記録します。 +`$orderId`や`$confirmationCode`はビジネス上の本質的な値です。一方`$been`は、いつ・誰が・何を根拠に完了したかという証跡を記録します。 ## 内側からの完全性 diff --git a/manuals/1.0/ja/04a-becoming.md b/manuals/1.0/ja/04a-becoming.md index 02f192a..851098b 100644 --- a/manuals/1.0/ja/04a-becoming.md +++ b/manuals/1.0/ja/04a-becoming.md @@ -19,7 +19,7 @@ permalink: /manuals/1.0/ja/04a-becoming.html $finalObject = $becoming(new EmailInput($name, $email)); ``` -`EmailInput` → `EmailValidation` → `UserCreation` → `WelcomeMessage`。各クラスの`#[Be()]`宣言に従い、チェーン全体が自動的に実行されます。各オブジェクトは生まれた瞬間に次の存在へと引き継がれ、消滅します。存在が無になり、無から次の存在が生まれる——この運動がチェーンの終端まで続きます。 +`EmailInput` → `EmailValidation` → `UserCreation` → `WelcomeMessage`。各クラスの`#[Be()]`宣言に従い、チェーン全体が自動的に実行されます。各オブジェクトは生まれた瞬間に次の存在へと引き継がれ、消滅します。各オブジェクトは次のオブジェクトを生み出すと消滅し、この連鎖が終端まで続きます。 ## Becomingの取得 @@ -39,7 +39,7 @@ final readonly class UserRegistrationPage } ``` -呼び出し側が知るのは、何を入れて何が出てくるかだけです。途中の変容は`#[Be()]`宣言が決めます。 +呼び出し側が知るのは、入力と出力だけです。途中の変容は`#[Be()]`宣言が決めます。 ## ネストした生成 diff --git a/manuals/1.0/ja/05-metamorphosis-patterns.md b/manuals/1.0/ja/05-metamorphosis-patterns.md index f14b650..ea7ff28 100644 --- a/manuals/1.0/ja/05-metamorphosis-patterns.md +++ b/manuals/1.0/ja/05-metamorphosis-patterns.md @@ -13,7 +13,7 @@ permalink: /manuals/1.0/ja/05-metamorphosis.html ## 時間とドメインは分割できない -アインシュタインが時間と空間の不可分性を発見したように、Beフレームワークでは時間とドメインは分割できない一つの実体です。承認プロセスには承認の時間が、決済には決済の時間があり、それぞれのドメインロジックが持つ固有の時間軸に沿って変容が自然に現れます。 +アインシュタインが時間と空間の不可分性を発見したように、Be Frameworkでは時間とドメインは分割できない一つの実体です。承認プロセスには承認の時間が、決済には決済の時間があり、それぞれのドメインロジックが持つ固有の時間軸に沿って変容が自然に現れます。 ## 不可逆的時間の流れ @@ -64,7 +64,7 @@ final readonly class ApplicationReview ## 型による継続 -`#[Be()]`で指定された候補クラスの中から、現在のオブジェクトのpublicプロパティの型がコンストラクタの`#[Input]`引数にマッチするクラスが自動的に選択されます： +次の変容先は自動的に選択されます。具体的には、`#[Be()]`で指定された候補クラスのうち、現在のオブジェクトのpublicプロパティの型と`#[Input]`引数の型が一致するクラスが選ばれます： ```php // ApplicationReviewのプロパティがApprovedApplication型なら @@ -84,16 +84,16 @@ final readonly class ApprovalNotification ## 自己組織化パイプライン -Unixパイプが単純なコマンドを組み合わせて強力なシステムを作るように、Beフレームワークは型付きオブジェクトを組み合わせて自然な変容の流れを作ります。 +Unixパイプが単純なコマンドを組み合わせて強力なシステムを作るように、Be Frameworkは型付きオブジェクトを組み合わせて自然な変容の流れを作ります。 ```bash # Unix: テキストが流れる外部制御のパイプライン cat access.log | grep "404" | awk '{print $7}' | sort | uniq -c ``` -Unixではshellがパイプを制御しますが、Beフレームワークではオブジェクト自身が`#[Be()]`で運命を宣言します。コントローラーもオーケストレーターといった、外部の制御が存在しません。 +Unixではshellがパイプを制御しますが、Be Frameworkではオブジェクト自身が`#[Be()]`で運命を宣言します。コントローラーやオーケストレーターのような外部の制御は存在しません。 -ヘラクレイトスは「流れているのが川だ」と言いました。川が流れるのではなく、流れそのものが川であるように、Beフレームワークのドメインは終端まで静止することがない時間的存在です。 +ヘラクレイトスは「流れているのが川だ」と言いました。川が流れるのではなく、流れそのものが川であるように、Be Frameworkのドメインは、終端に至るまで流れ続ける時間的存在です。 --- diff --git a/manuals/1.0/ja/06-semantic-variables.md b/manuals/1.0/ja/06-semantic-variables.md index d097f8f..aca3566 100644 --- a/manuals/1.0/ja/06-semantic-variables.md +++ b/manuals/1.0/ja/06-semantic-variables.md @@ -31,11 +31,11 @@ final class Email public function __construct(string $email) {} ``` -一度定義すれば、`$email`という名前のすべてのコンストラクタ引数に自動的に適用されます。`$email`の値が正しいのは偶然ではなく、必然です。正しくなれないものは存在できません。 +一度定義すれば、`$email`という名前のすべてのコンストラクタ引数に自動的に適用されます。`$email`の値は常に正しいことが保証されます。正しくない値は存在できません。 -## 名前の装飾 +## 属性による制約の拡張 -同じ名前に属性を加えることで、存在条件をより精密にできます。`#[Validate]`メソッドに属性が付いている場合、コンストラクタ引数の属性とマッチしたときだけ実行されます： +同じ名前に属性を加えることで、存在条件をより精密にできます。`#[Validate]`属性が付いたメソッドの引数にPHP属性がある場合、コンストラクタ引数に同じ属性があるときだけ実行されます： ```php // $ageの基本制約（0-150歳） @@ -72,7 +72,7 @@ public function __construct(#[Teen] int $age) {} ## 名前が関係を持つ -意味変数は単独の制約だけでなく、変数間の関係も制約として持ちます。`#[Validate]`メソッドの引数名がコンストラクタの引数名と部分マッチすると、対応する値が自動的に渡されます： +意味変数は単独の制約だけでなく、変数間の関係も制約として持ちます。`#[Validate]`属性が付いたメソッドの引数名がコンストラクタの引数名と部分一致すると、対応する値が自動的に渡されます： ```php // フォーマット検証 — メールアドレスの一致確認 diff --git a/manuals/1.0/ja/08-reason-layer.md b/manuals/1.0/ja/08-reason-layer.md index 204d489..112265c 100644 --- a/manuals/1.0/ja/08-reason-layer.md +++ b/manuals/1.0/ja/08-reason-layer.md @@ -13,7 +13,7 @@ permalink: /manuals/1.0/ja/08-reason-layer.html ## 存在の理由 -`ExpressDelivery`がその存在でいられるのは、速達配送の能力を持っているからです。`StandardDelivery`がその存在でいられるのは、通常配送の能力を持っているからです。この「なぜその存在でいられるのか」の根拠が、**raison d'être**（レーゾンデートル：存在理由）です。 +`ExpressDelivery`が速達配送として成り立つのは、速達配送の能力を持っているからです。`StandardDelivery`が通常配送として成り立つのは、通常配送の能力を持っているからです。この「なぜその存在でいられるのか」の根拠が、**raison d'être**（レーゾンデートル：存在理由）です。 存在理由層は、このraison d'êtreを一つのオブジェクトとして表現する設計パターンです。 @@ -35,7 +35,7 @@ final readonly class ExpressDelivery ## $beingとしての存在理由 -存在理由オブジェクトは`$being`として渡されることで、もう一つの役割を担います。その**型**が変容先の判別根拠になると同時に、その存在様式に固有のメソッド群を提供します。 +存在理由オブジェクトは`$being`プロパティとしても使えます。このとき、そのオブジェクトの**型**が変容先の判別根拠になると同時に、その配送方式に固有のメソッドも提供します。 ```php final readonly class ExpressDelivery @@ -147,4 +147,4 @@ public function __construct( --- -存在できない事自体は存在します。[検証とエラーハンドリング](./09-error-handling.html)でその扱い方を学びます ➡️ +存在できなかった、という結果もまた扱う必要があります。[検証とエラーハンドリング](./09-error-handling.html)でその扱い方を学びます ➡️ diff --git a/manuals/1.0/ja/09-error-handling.md b/manuals/1.0/ja/09-error-handling.md index ba06483..4f5c194 100644 --- a/manuals/1.0/ja/09-error-handling.md +++ b/manuals/1.0/ja/09-error-handling.md @@ -35,7 +35,7 @@ catch (SemanticVariableException $e) { ## ドメイン例外クラス -すべての例外は`DomainException`を継承します。技術的例外（`RuntimeException`、`InvalidArgumentException`等）は使いません。失敗は常に**ドメインの意味を持つ失敗**として表現されます： +すべての例外は`DomainException`を継承します。ドメイン層では技術的例外（`RuntimeException`、`InvalidArgumentException`等）を使わず、常にドメイン例外を使います。失敗は常に**ドメインの意味を持つ失敗**として表現されます： ```php abstract class DomainException extends Exception {} @@ -109,7 +109,7 @@ try { } ``` -「即座に失敗」ではなく——**すべての問題を一度に理解**。 +最初のエラーで即座に失敗するのではなく、すべての問題を一度に把握できます。 ## エラーも存在の１つ diff --git a/manuals/1.0/ja/10-semantic-logging.md b/manuals/1.0/ja/10-semantic-logging.md index afabfeb..231e172 100644 --- a/manuals/1.0/ja/10-semantic-logging.md +++ b/manuals/1.0/ja/10-semantic-logging.md @@ -13,7 +13,7 @@ permalink: /manuals/1.0/ja/10-semantic-logging.html ## 概要 -Beフレームワークは、オブジェクトの変容プロセスを構造化されたログとして自動記録する**意味的ログ**機能を実装しています。 +Be Frameworkは、オブジェクトの変容プロセスを構造化されたログとして自動記録する**意味的ログ**機能を実装しています。 ### 基本コンセプト diff --git a/manuals/1.0/ja/12-philosophy-behind.md b/manuals/1.0/ja/12-philosophy-behind.md index e51a6f0..e79fd58 100644 --- a/manuals/1.0/ja/12-philosophy-behind.md +++ b/manuals/1.0/ja/12-philosophy-behind.md @@ -47,7 +47,7 @@ $user = $becoming(new UserInput($data)); アラン・ケイは、オブジェクトをメッセージでコミュニケーションする自律的な細胞として構想しました。しかし実際に生まれたものは、受動的なデータ構造を操作するコントローラーに近いものでした。 -Beフレームワークの一つの見方：オブジェクトが自らの変容に参加する——そのオリジナルのビジョンに近づこうとする試みです。 +Be Frameworkの一つの見方：オブジェクトが自らの変容に参加する——そのオリジナルのビジョンに近づこうとする試みです。 --- @@ -104,8 +104,6 @@ function processUser(ValidatedUser $user) { アイデア：エラーを処理するのではなく、特定のエラーを表現不可能にする。 -サルトルは「実存は本質に先立つ」と書きました—私たちはまず存在し、それから自分自身を定義します。Be Frameworkでは：存在は行動に先立つ—何であるかが何をできるかを決定します。 - --- ## 4. ヘラクレイトス：万物は流転する @@ -281,7 +279,7 @@ string $password // 名前がPassword検証を示唆 ## 9. 共鳴 -これらの哲学が、Beフレームワークと共鳴しています。 +これらの哲学が、Be Frameworkと共鳴しています。 | 出典 | 概念 | Beでの表現 | |------|------|----------------------| diff --git a/manuals/1.0/ja/13-vision-ldd.md b/manuals/1.0/ja/13-vision-ldd.md index 65d078c..15d6ad4 100644 --- a/manuals/1.0/ja/13-vision-ldd.md +++ b/manuals/1.0/ja/13-vision-ldd.md @@ -67,11 +67,11 @@ TDD（テスト駆動開発）が「振る舞い（Doing）」を定義してか ## 結論: Code as Philosophy -冒頭の「胡蝶の夢」は古代の中国の思想家の荘子の逸話です。 +冒頭で引用した「胡蝶の夢」はこう伝えています。 > 夢の中で胡蝶（蝶のこと）としてひらひらと飛んでいた所、目が覚めたが、はたして自分は蝶になった夢をみていたのか、それとも実は夢でみた蝶こそが本来の自分であって今の自分は蝶が見ている夢なのか LDDでログがコードになりえるのはまさにこの胡蝶の夢で、Be Frameworkの完全な透明性が、ログとコードの意味の境界を曖昧にします。意味的ログはいわば、アプリケーション実行のDSLです。その時、思想が言葉になり、言葉がコードになり、コードが物語になる。 Be Frameworkにおけるプログラミングは、単にコンピュータに命令することではありません。 -それはまるで生命のようなデジタル空間における「時間的存在」を定義し、その変容の意味が物語（Log）を紡ぎ出させる行為なのです。 +それは、デジタル空間に生命のような「時間的存在」を定義し、その変容が自ら物語（Log）を紡ぎ出す行為です。 diff --git a/manuals/1.0/ja/14-faq.md b/manuals/1.0/ja/14-faq.md index 7718900..0461847 100644 --- a/manuals/1.0/ja/14-faq.md +++ b/manuals/1.0/ja/14-faq.md @@ -11,7 +11,7 @@ permalink: /manuals/1.0/ja/faq.html ### Q. これは新しい"プログラミングパラダイム"ですか？ -A. はい。Be Frameworkは、 時間的存在を一次市民に据え、「何をするか」ではなく「何であるか」に基づいて設計します。 +A. はい。Be Frameworkは、 時間的存在を第一級市民（first-class citizen）に据え、「何をするか」ではなく「何であるか」に基づいて設計します。 思想面では大きなパラダイム転換ですが、実装面ではOOP/FP/DDDと共存可能で、既存スタイルを置き換える必要はありません。 @@ -23,9 +23,9 @@ A. はい。Be Frameworkは、 時間的存在を一次市民に据え、「何 A. レイヤーが異なり、共存できます。 -Web MVCは実質的に入出力の責務分割として機能し、DDDはドメインのモデリング手法です。Be Frameworkは「存在の条件と時間的変容」でオブジェクトの生成を組み立てる設計パラダイムで、MVCのControllerから呼び出すことも、DDDの集約の内部で使うこともできます。 +Web MVCは実質的に入出力の責務分割であり、DDDはドメインのモデリング手法です。Be Frameworkは「存在の条件と時間的変容」でオブジェクトの生成を組み立てる設計パラダイムで、MVCのControllerから呼び出すことも、DDDの集約の内部で使うこともできます。 -興味深いことに、MVCが本来目指した「メンタルモデルの投影」と、DDDが目指した「ビジネスの言葉でコードを書く」は、存在型と意味変数を通じてBe Frameworkで自然に実現されています。 +興味深いことに、MVCが目指した「メンタルモデルの投影」とDDDが目指した「ビジネスの言葉でコードを書く」は、Be Frameworkの存在型と意味変数によって自然に実現されています。 ### Q1-a. CQRSとはどう関係しますか？ @@ -290,7 +290,7 @@ $user = $becoming(new UserInput($name, $email)); ## 9) 重要用語の詳細解説 ### 存在指向 / Ontological（オントロジカル） -「何をするか」ではなく「何が存在できるか」を中心に据える設計思想です。存在可能性と時間を一次の抽象として扱い、プログラムの状態を時間的な存在として捉えます。その結果、存在できない状態は型として表現されないため、不正状態が自然に排除されます。 +「何をするか」ではなく「何が存在できるか」を中心に据える設計思想です。存在可能性と時間を第一級の抽象として扱い、プログラムの状態を時間的な存在として捉えます。その結果、存在できない状態は型として表現されないため、不正状態が自然に排除されます。 ### イマナンス / トランセンデンス（内在 / 超越） 内在（`#[Input]`）はオブジェクトが本来持つ性質、超越（`#[Inject]`）は外部から与えられる力です。変容は常に「内在 + 超越 → 新しい内在」の公式に従います。超越は内在を変え、自らは消えていきます。 diff --git a/manuals/1.0/ja/demos.md b/manuals/1.0/ja/demos.md index 19ed0d5..361f8cc 100644 --- a/manuals/1.0/ja/demos.md +++ b/manuals/1.0/ja/demos.md @@ -126,7 +126,7 @@ final readonly class PaymentCompleted implements MomentInterface #### Reason（存在理由） -Reasonは**内在と超越が出会う場所** - 内部データを外部システムやドメインルールに接続するステートレスなゲートウェイです。 +Reasonは内部データと外部システムを接続するステートレスなゲートウェイです。内在と超越が出会う場所とも言えます。 ```php final class PaymentGateway implements PaymentGatewayInterface diff --git a/manuals/1.0/ja/getting-started.md b/manuals/1.0/ja/getting-started.md index 191d12e..9938e2b 100644 --- a/manuals/1.0/ja/getting-started.md +++ b/manuals/1.0/ja/getting-started.md @@ -122,7 +122,7 @@ Hello (Greeting が注入された状態) → "Hello World" ``` -入力オブジェクトは何もしていません — 変容を通じて Hello になった(BEING)のです。 +入力オブジェクトは何も「していません」。変容を通じてHelloに「なった」のです。 ## セマンティック検証を試す diff --git a/manuals/1.0/ja/index.md b/manuals/1.0/ja/index.md index 3952d68..11658db 100644 --- a/manuals/1.0/ja/index.md +++ b/manuals/1.0/ja/index.md @@ -4,7 +4,7 @@ title: イントロダクション category: Manual permalink: /manuals/1.0/ja/ --- -# Beフレームワーク マニュアル +# Be Framework マニュアル > 変容を通じて存在を理解する @@ -12,22 +12,22 @@ permalink: /manuals/1.0/ja/ 新しいパラダイム：存在指向プログラミングとの出会い ## [2. 入力クラス](./02-input-classes.html) -変容の出発点 - 純粋な内在的本質 +変容の出発点 — 外部に依存しない純粋なデータ ## [3. 存在クラス](./03-being-classes.html) -内在+超越的相互作用による中間変容 +外部の力と出会い、変容する中間段階 ## [4. 最終オブジェクト](./04-final-objects.html) 変容の目的地 - 完全に変容した存在 ## [5. 変容](./05-metamorphosis.html) -時間とドメインの不可分性、運命の自己決定 +時間に沿った変容と、オブジェクト自身による分岐 ## [6. 意味変数](./06-semantic-variables.html) -ドメイン固有の検証と存在論的型安全性 +変数名が意味と検証ルールを持つ仕組み ## [8. 存在理由層](./08-reason-layer.html) -オブジェクトの存在を可能にする理由と存在根拠 +オブジェクトが成り立つための根拠をまとめる ## [9. 意味例外](./09-error-handling.html) 意味的例外と多言語エラーメッセージ diff --git a/manuals/1.0/ja/tutorial.md b/manuals/1.0/ja/tutorial.md index a30dbef..9b40497 100644 --- a/manuals/1.0/ja/tutorial.md +++ b/manuals/1.0/ja/tutorial.md @@ -96,7 +96,7 @@ final class LethalVitalException extends DomainException ## ステップ 3: Reason（超越）を定義する -JTASProtocol（Japan Triage and Acuity Scale）は開発者の恣意的なルールではありません。超越的な医学の知恵—世界に独立して存在する客観的な知識—を表します。Be Framework では、このようなドメインロジックは第一級市民(first class citizen)になります：注入可能、テスト可能で明示的に表されます。 +JTASProtocol（Japan Triage and Acuity Scale）は開発者の恣意的なルールではありません。超越的な医学の知恵、つまり世界に独立して存在する客観的な知識を表します。Be Frameworkでは、このようなドメインロジックを第一級市民として扱います。注入可能でテスト可能、かつ明示的に表現されます。 ```php // src/Reason/JTASProtocol.php @@ -155,7 +155,7 @@ final readonly class Emergency {} // 緊急 final readonly class Observation {} // 経過観察 ``` -これらは空のクラスではありません—それ自体が**区別**です。`Emergency` は `Observation` とは根本的に異なり型自体が意味を持ちます。 +これらは中身のないクラスに見えますが、型そのものが意味を持ちます。`Emergency` は `Observation` とは根本的に異なり型自体が意味を持ちます。 ## ステップ 6: Being クラスを作成 From a26a8316522912fbd894f1ef2508a5f9963a7eae Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 20 Mar 2026 11:26:40 +0900 Subject: [PATCH 2/5] Fix 3 issues found in self-review of Japanese expression changes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 04a-becoming: Remove duplicated sentence about object lifecycle - tutorial: Fix repeated "型が意味を持ちます" in same sentence - 08-reason-layer: Revert "配送方式" back to "存在様式" (generic, not domain-specific) Co-Authored-By: Claude Opus 4.6 (1M context) --- manuals/1.0/ja/04a-becoming.md | 2 +- manuals/1.0/ja/08-reason-layer.md | 2 +- manuals/1.0/ja/tutorial.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/manuals/1.0/ja/04a-becoming.md b/manuals/1.0/ja/04a-becoming.md index 851098b..cc9af91 100644 --- a/manuals/1.0/ja/04a-becoming.md +++ b/manuals/1.0/ja/04a-becoming.md @@ -19,7 +19,7 @@ permalink: /manuals/1.0/ja/04a-becoming.html $finalObject = $becoming(new EmailInput($name, $email)); ``` -`EmailInput` → `EmailValidation` → `UserCreation` → `WelcomeMessage`。各クラスの`#[Be()]`宣言に従い、チェーン全体が自動的に実行されます。各オブジェクトは生まれた瞬間に次の存在へと引き継がれ、消滅します。各オブジェクトは次のオブジェクトを生み出すと消滅し、この連鎖が終端まで続きます。 +`EmailInput` → `EmailValidation` → `UserCreation` → `WelcomeMessage`。各クラスの`#[Be()]`宣言に従い、チェーン全体が自動的に実行されます。各オブジェクトは次のオブジェクトを生み出すと消滅し、この連鎖が終端まで続きます。 ## Becomingの取得 diff --git a/manuals/1.0/ja/08-reason-layer.md b/manuals/1.0/ja/08-reason-layer.md index 112265c..2f0f79e 100644 --- a/manuals/1.0/ja/08-reason-layer.md +++ b/manuals/1.0/ja/08-reason-layer.md @@ -35,7 +35,7 @@ final readonly class ExpressDelivery ## $beingとしての存在理由 -存在理由オブジェクトは`$being`プロパティとしても使えます。このとき、そのオブジェクトの**型**が変容先の判別根拠になると同時に、その配送方式に固有のメソッドも提供します。 +存在理由オブジェクトは`$being`プロパティとしても使えます。このとき、そのオブジェクトの**型**が変容先の判別根拠になると同時に、その存在様式に固有のメソッドも提供します。 ```php final readonly class ExpressDelivery diff --git a/manuals/1.0/ja/tutorial.md b/manuals/1.0/ja/tutorial.md index 9b40497..9a6877f 100644 --- a/manuals/1.0/ja/tutorial.md +++ b/manuals/1.0/ja/tutorial.md @@ -155,7 +155,7 @@ final readonly class Emergency {} // 緊急 final readonly class Observation {} // 経過観察 ``` -これらは中身のないクラスに見えますが、型そのものが意味を持ちます。`Emergency` は `Observation` とは根本的に異なり型自体が意味を持ちます。 +これらは中身のないクラスに見えますが、型そのものが意味を持ちます。`Emergency` は `Observation` とは根本的に異なる存在です。 ## ステップ 6: Being クラスを作成 From a6cbfaa80f4e27d3bffb6f1c764825dad7704f51 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 20 Mar 2026 11:37:20 +0900 Subject: [PATCH 3/5] Restore rich expressions that were over-simplified MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Restore "全能の自由"/"無限の責任" contrast in 01-overview - Restore seed metaphor before gardener section in 01-overview - Restore plant self-transformation language in 01-overview - Restore "偶然ではなく、必然" echoing Spinoza in 06-semantic-variables - Restore "何を入れて何が出てくるか" in 04a-becoming - Restore original Doing/Being contrast in getting-started - Fix dash inconsistency (hyphen → em dash) in index.md - Fix noun-phrase style consistency in index.md - Rewrite confusing "引数にPHP属性がある場合" in 06-semantic-variables Co-Authored-By: Claude Opus 4.6 (1M context) --- manuals/1.0/ja/01-overview.md | 6 +++--- manuals/1.0/ja/04a-becoming.md | 2 +- manuals/1.0/ja/06-semantic-variables.md | 4 ++-- manuals/1.0/ja/getting-started.md | 2 +- manuals/1.0/ja/index.md | 4 ++-- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/manuals/1.0/ja/01-overview.md b/manuals/1.0/ja/01-overview.md index b3b52a4..b338764 100644 --- a/manuals/1.0/ja/01-overview.md +++ b/manuals/1.0/ja/01-overview.md @@ -75,15 +75,15 @@ function archiveUser(DeletedUser $user) { } 従来のMVCフレームワークでは、コントローラーがアプリケーション全体の流れを制御します。しかし、システムが複雑になるにつれて、この「全てを制御しようとするアプローチ」は困難になります。 -コントローラーはあらゆるモデルやコンポーネントにアクセスできます。しかし制約がない分、すべての手続きの整合性を自分で保つ責任を負います。 +コントローラーは全てのモデルやコンポーネントに無制限にアクセスできる「全能の自由」を持っています。しかし制約がないということは、システム内のあらゆる手続きの整合性を自分で保つという「無限の責任」を負うことを意味します。 -Be Frameworkは異なるアプローチを採ります。外部から操作してデータを組み立てるのではなく、シンプルな入力オブジェクトが自ら最終オブジェクトへと変容していきます。 +Be Frameworkは異なるアプローチを採ります。操作が目的のデータをつくり出すのではなく、種子のような単純な入力オブジェクトが他のオブジェクトと出会い、自然に成長し、最終オブジェクトへと自ら変容していきます。 ### Commander (司令官) から Gardener (庭師) へ: * 司令官は部下（オブジェクト）に「動け」と命令します。しかし、システムが複雑になるほど、すべてを命令で制御し続けるのは困難です。 * 庭師は、植物に命令しません。ただ、水や光という環境を整えるだけです。 -植物は環境を受け入れ、自らの力で成長します。Be Frameworkのオブジェクトも同じです。入力を受け取ると、自ら最終オブジェクトへと変容していきます。制御を手放し、自律的な変容に委ねる。これがBe Frameworkのコアコンセプトです。 +植物は環境を受け入れ、自らを自律的に変容させ、あるべき姿に成ります。Be Frameworkも同じです。入力を与えると、自らが最終オブジェクトになるような環境を整えます。制御を手放し、自律的な変容に委ねる。これがBe Frameworkのコアコンセプトです。 ## このマニュアルで学べること diff --git a/manuals/1.0/ja/04a-becoming.md b/manuals/1.0/ja/04a-becoming.md index cc9af91..23f0609 100644 --- a/manuals/1.0/ja/04a-becoming.md +++ b/manuals/1.0/ja/04a-becoming.md @@ -39,7 +39,7 @@ final readonly class UserRegistrationPage } ``` -呼び出し側が知るのは、入力と出力だけです。途中の変容は`#[Be()]`宣言が決めます。 +呼び出し側が知るのは、何を入れて何が出てくるかだけです。途中の変容は`#[Be()]`宣言が決めます。 ## ネストした生成 diff --git a/manuals/1.0/ja/06-semantic-variables.md b/manuals/1.0/ja/06-semantic-variables.md index aca3566..1fdb09a 100644 --- a/manuals/1.0/ja/06-semantic-variables.md +++ b/manuals/1.0/ja/06-semantic-variables.md @@ -31,11 +31,11 @@ final class Email public function __construct(string $email) {} ``` -一度定義すれば、`$email`という名前のすべてのコンストラクタ引数に自動的に適用されます。`$email`の値は常に正しいことが保証されます。正しくない値は存在できません。 +一度定義すれば、`$email`という名前のすべてのコンストラクタ引数に自動的に適用されます。`$email`の値が正しいのは偶然ではなく、必然です。正しくなれないものは存在できません。 ## 属性による制約の拡張 -同じ名前に属性を加えることで、存在条件をより精密にできます。`#[Validate]`属性が付いたメソッドの引数にPHP属性がある場合、コンストラクタ引数に同じ属性があるときだけ実行されます： +同じ名前に属性を加えることで、存在条件をより精密にできます。`#[Validate]`属性が付いたメソッドでは、メソッド引数に属性（例: `#[Teen]`）が指定されていると、コンストラクタ側に同じ属性があるときだけ実行されます： ```php // $ageの基本制約（0-150歳） diff --git a/manuals/1.0/ja/getting-started.md b/manuals/1.0/ja/getting-started.md index 9938e2b..191d12e 100644 --- a/manuals/1.0/ja/getting-started.md +++ b/manuals/1.0/ja/getting-started.md @@ -122,7 +122,7 @@ Hello (Greeting が注入された状態) → "Hello World" ``` -入力オブジェクトは何も「していません」。変容を通じてHelloに「なった」のです。 +入力オブジェクトは何もしていません — 変容を通じて Hello になった(BEING)のです。 ## セマンティック検証を試す diff --git a/manuals/1.0/ja/index.md b/manuals/1.0/ja/index.md index 11658db..f3fc681 100644 --- a/manuals/1.0/ja/index.md +++ b/manuals/1.0/ja/index.md @@ -18,7 +18,7 @@ permalink: /manuals/1.0/ja/ 外部の力と出会い、変容する中間段階 ## [4. 最終オブジェクト](./04-final-objects.html) -変容の目的地 - 完全に変容した存在 +変容の目的地 — 完全に変容した存在 ## [5. 変容](./05-metamorphosis.html) 時間に沿った変容と、オブジェクト自身による分岐 @@ -27,7 +27,7 @@ permalink: /manuals/1.0/ja/ 変数名が意味と検証ルールを持つ仕組み ## [8. 存在理由層](./08-reason-layer.html) -オブジェクトが成り立つための根拠をまとめる +オブジェクトが成り立つための根拠と道具一式 ## [9. 意味例外](./09-error-handling.html) 意味的例外と多言語エラーメッセージ From b8fe253201c7f6abb3ac332fba39ac664b26e680 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 20 Mar 2026 12:01:07 +0900 Subject: [PATCH 4/5] =?UTF-8?q?Add=20back=20"=E4=BB=96=E8=80=85=E3=82=92?= =?UTF-8?q?=E5=A4=89=E3=81=88=E3=82=88=E3=81=86=E3=81=A8=E3=81=9B=E3=81=9A?= =?UTF-8?q?"=20to=20plant=20metaphor?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Restores the contrast with the Commander pattern: commanders control others, plants transform only themselves. Co-Authored-By: Claude Opus 4.6 (1M context) --- manuals/1.0/ja/01-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manuals/1.0/ja/01-overview.md b/manuals/1.0/ja/01-overview.md index b338764..9dd26a4 100644 --- a/manuals/1.0/ja/01-overview.md +++ b/manuals/1.0/ja/01-overview.md @@ -83,7 +83,7 @@ Be Frameworkは異なるアプローチを採ります。操作が目的のデ * 司令官は部下（オブジェクト）に「動け」と命令します。しかし、システムが複雑になるほど、すべてを命令で制御し続けるのは困難です。 * 庭師は、植物に命令しません。ただ、水や光という環境を整えるだけです。 -植物は環境を受け入れ、自らを自律的に変容させ、あるべき姿に成ります。Be Frameworkも同じです。入力を与えると、自らが最終オブジェクトになるような環境を整えます。制御を手放し、自律的な変容に委ねる。これがBe Frameworkのコアコンセプトです。 +植物は他者を変えようとせず、環境を受け入れて自らを変容させ、あるべき姿に成ります。Be Frameworkも同じです。入力を与えると、自らが最終オブジェクトになるような環境を整えます。制御を手放し、自律的な変容に委ねる。これがBe Frameworkのコアコンセプトです。 ## このマニュアルで学べること From 399a077d7e97a68d522ad24032a4b6632189236f Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Fri, 20 Mar 2026 12:07:00 +0900 Subject: [PATCH 5/5] Fix English manual: remove Sartre, improve phrasing - Remove Sartre reference to match Japanese version (contradicts framework's position) - Rephrase "no external control such as controllers or orchestrators" for clarity Co-Authored-By: Claude Opus 4.6 (1M context) --- manuals/1.0/en/05-metamorphosis-patterns.md | 2 +- manuals/1.0/en/12-philosophy-behind.md | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/manuals/1.0/en/05-metamorphosis-patterns.md b/manuals/1.0/en/05-metamorphosis-patterns.md index 643dc6d..0097437 100644 --- a/manuals/1.0/en/05-metamorphosis-patterns.md +++ b/manuals/1.0/en/05-metamorphosis-patterns.md @@ -91,7 +91,7 @@ Like UNIX pipes that combine simple commands to create powerful systems, Be Fram cat access.log | grep "404" | awk '{print $7}' | sort | uniq -c ``` -In UNIX, the shell controls the pipeline. In Be Framework, objects declare their own destiny with `#[Be()]`. There is no external control such as controllers or orchestrators. +In UNIX, the shell controls the pipeline. In Be Framework, objects declare their own destiny with `#[Be()]`—no controller or orchestrator controls the flow. Heraclitus said "the flowing is the river." Just as it is not that a river flows, but that the flowing itself is the river, domains in the Be Framework are temporal existence that never rest until they reach their end. diff --git a/manuals/1.0/en/12-philosophy-behind.md b/manuals/1.0/en/12-philosophy-behind.md index e733e6c..d3d0bc7 100644 --- a/manuals/1.0/en/12-philosophy-behind.md +++ b/manuals/1.0/en/12-philosophy-behind.md @@ -104,8 +104,6 @@ function processUser(ValidatedUser $user) { The idea: rather than handling errors, make certain errors impossible to represent. -Sartre wrote "Existence precedes essence"—we exist first, then define ourselves. In Be Framework: Existence precedes action—what you ARE determines what you CAN DO. - --- ## 4. Heraclitus: Everything Flows