diff --git a/_includes/manuals/1.0/en/contents.html b/_includes/manuals/1.0/en/contents.html index e3930fa..8b7dbfc 100644 --- a/_includes/manuals/1.0/en/contents.html +++ b/_includes/manuals/1.0/en/contents.html @@ -16,15 +16,19 @@ - + \ No newline at end of file diff --git a/_includes/manuals/1.0/ja/contents.html b/_includes/manuals/1.0/ja/contents.html index 707221b..85bc93d 100644 --- a/_includes/manuals/1.0/ja/contents.html +++ b/_includes/manuals/1.0/ja/contents.html @@ -16,15 +16,19 @@ - + \ No newline at end of file diff --git a/index.html b/index.html index e35a05b..f9b1755 100644 --- a/index.html +++ b/index.html @@ -11,7 +11,18 @@ The Ontological Programming Framework for PHP

- + Learn more » + diff --git a/manuals/1.0/en/01-overview.md b/manuals/1.0/en/01-overview.md index 1dc98aa..3361b5f 100644 --- a/manuals/1.0/en/01-overview.md +++ b/manuals/1.0/en/01-overview.md @@ -5,7 +5,11 @@ category: Manual permalink: /manuals/1.0/en/01-overview.html --- -# Overview: A Different Way to Think About Code +# A Different Way to Think About Code + +> "The real voyage of discovery consists not in seeking new landscapes, but in having new eyes." +> +> —Marcel Proust, 'The Prisoner' (In Search of Lost Time, Volume 5) 1923 ## First, Look at This diff --git a/manuals/1.0/en/02-input-classes.md b/manuals/1.0/en/02-input-classes.md index 9720c34..54914ba 100644 --- a/manuals/1.0/en/02-input-classes.md +++ b/manuals/1.0/en/02-input-classes.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/en/02-input-classes.html # Input Classes +> "We begin from conditions we did not choose, and from there we build our existence." +> +> —From Heidegger's concept of Geworfenheit (thrownness) in 'Being and Time' (1927) + +## The Beginning + Input Classes are the starting point of every transformation in Be Framework. They contain only what the object itself possesses—no external dependencies. Think of it as the object's identity. These elements exist within the object, forming what we call the object's **Immanent Nature**. diff --git a/manuals/1.0/en/03-being-classes.md b/manuals/1.0/en/03-being-classes.md index d38d993..c7fe6f7 100644 --- a/manuals/1.0/en/03-being-classes.md +++ b/manuals/1.0/en/03-being-classes.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/en/03-being-classes.html # Being Classes +> "The Tao does nothing, yet nothing is left undone." +> +> —Laozi, Tao Te Ching, Chapter 37 (6th century BC) + +## Immanence Meets Transcendence + Being Classes are where transformation actually occurs. The object's own nature (**Immanent Nature**) meets forces provided from the outside (**Transcendent Forces**), and a new being is born. If Input Classes are the "beginning," Being Classes express the "moment of change." diff --git a/manuals/1.0/en/04-final-objects.md b/manuals/1.0/en/04-final-objects.md index 45f2e3b..d0aa83f 100644 --- a/manuals/1.0/en/04-final-objects.md +++ b/manuals/1.0/en/04-final-objects.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/en/04-final-objects.html # Final Objects +> "You are not me. How can you know that I don't know the feelings of fish?" +> +> —Zhuangzi's reply when asked "You are not a fish. How can you know the feelings of fish?" (Zhuangzi, 4th century BC) + +## The Destination + Final Objects represent the destination of metamorphosis—complete, transformed beings that embody the user's actual interest. These are what the application ultimately cares about. ## Characteristics of Final Objects @@ -17,9 +23,20 @@ Final Objects represent the destination of metamorphosis—complete, transformed **Rich State**: Unlike Input Classes, Final Objects contain the full richness of transformed data. +## Temporal Completeness + +Here's an intriguing question: What if objects had such completeness that they needed no external testing? + +The Be Framework captures the temporal existence of objects along two axes: + +- **`#[Be]`**: The intended self, the destination (future directionality) +- **`$been`**: The completed self (past perfect self-evidence) + +Traditional programming verifies whether objects have been processed correctly through external tests. But what if objects themselves contained evidence of their completion? Instead of external verification, intrinsic self-evidence becomes possible. + ## Examples -### Successful Outcomes +### Intrinsic Self-Evidence ```php final class SuccessfulOrder { @@ -27,43 +44,71 @@ final class SuccessfulOrder public readonly string $confirmationCode; public readonly DateTimeImmutable $timestamp; public readonly string $message; + public readonly BeenProcessed $been; // Self-evidence public function __construct( - #[Input] Money $total, // Immanent from validation - #[Input] CreditCard $card, // Immanent from validation - #[Inject] OrderIdGenerator $generator, // Transcendent - #[Inject] Receipt $receipt // Transcendent + #[Input] Money $total, // Immanent nature + #[Input] CreditCard $card, // Immanent nature + #[Inject] OrderIdGenerator $generator, // Transcendent force + #[Inject] Receipt $receipt // Transcendent force ) { - $this->orderId = $generator->generate(); // New Immanent - $this->confirmationCode = $receipt->generate($total); // New Immanent - $this->timestamp = new DateTimeImmutable(); // New Immanent - $this->message = "Order confirmed: {$this->orderId}"; // New Immanent + $this->orderId = $generator->generate(); // New immanent nature + $this->confirmationCode = $receipt->generate($total); // New immanent nature + $this->timestamp = new DateTimeImmutable(); // New immanent nature + $this->message = "Order confirmed: {$this->orderId}"; // New immanent nature + + // Self-evidence of completion + $this->been = new BeenProcessed( + actor: $card->getHolderName(), + timestamp: $this->timestamp, + evidence: [ + 'total' => $total->getAmount(), + 'payment_method' => $card->getType(), + 'confirmation' => $this->confirmationCode + ] + ); } } ``` -### Error States as Final Objects +This object requires no external testing. The `$been` property contains complete evidence of completion. + +### Error States with Self-Evidence ```php final class FailedOrder { public readonly string $errorCode; public readonly string $message; public readonly DateTimeImmutable $timestamp; + public readonly BeenRejected $been; // Self-evidence of failure public function __construct( - #[Input] array $errors, // Immanent from validation - #[Inject] Logger $logger, // Transcendent - #[Inject] ErrorCodeGenerator $generator // Transcendent + #[Input] array $errors, // Immanent nature + #[Inject] Logger $logger, // Transcendent force + #[Inject] ErrorCodeGenerator $generator // Transcendent force ) { $this->errorCode = $generator->generate(); $this->message = "Order failed: " . implode(', ', $errors); $this->timestamp = new DateTimeImmutable(); + // Self-evidence of failure + $this->been = new BeenRejected( + reason: 'validation_failed', + timestamp: $this->timestamp, + evidence: [ + 'error_count' => count($errors), + 'error_types' => array_keys($errors), + 'error_code' => $this->errorCode + ] + ); + $logger->logOrderFailure($this->errorCode, $errors); // Side effect } } ``` +Both success and failure carry their own self-evidence of completion. Instead of external tests, the objects themselves maintain complete records of what occurred. + ## Final Objects vs Input Classes | Input Classes | Final Objects | @@ -99,8 +144,12 @@ The path from Input to Final Object represents a complete transformation journey 2. **Being Classes**: Transformation stages ("Here's how I change") 3. **Final Object**: Complete result ("Here's what I became") -Users primarily care about Input (what they provide) and Final Objects (what they get back). The Being Classes in between are the framework's responsibility—the machinery of transformation that creates the bridge between intention and result. +Users primarily care about Input (what they provide) and Final Objects (what they get back). The Being Classes in between are our responsibility as designers. It's crucial to understand the temporal transformation of the domain well and design the mechanisms of that transformation to bridge intention and result. + +## Transformation Complete + +Final Objects express the state of entelecheia (complete realization). They are fully realized beings that no longer need transformation. -## Natural Completion +The immanent nature that began with Input Classes, through encounters with various transcendent forces and natural transformation, finally reaches this completed form. There is no more "trying to become" or "intending to change." Everything is complete, and the value that users truly sought is realized here. This is the essential value of our system. -Final Objects embody the completion of natural transformation. They don't need to "do" anything more—they simply *are* the result that was meant to emerge from the original input's encounter with the world's capabilities. +This is the destination that Be Framework aims for in programming—existence that embodies not "what to do" but "what to be." diff --git a/manuals/1.0/en/05-metamorphosis-patterns.md b/manuals/1.0/en/05-metamorphosis-patterns.md index 42a80e8..8568e29 100644 --- a/manuals/1.0/en/05-metamorphosis-patterns.md +++ b/manuals/1.0/en/05-metamorphosis-patterns.md @@ -1,40 +1,46 @@ --- layout: docs-en -title: "5. Metamorphosis Patterns" +title: "5. Metamorphosis" category: Manual -permalink: /manuals/1.0/en/05-metamorphosis-patterns.html +permalink: /manuals/1.0/en/05-metamorphosis.html --- -# Metamorphosis Patterns +# Metamorphosis -Be Framework supports various patterns of transformation, from simple linear chains to complex branching destinies. Understanding these patterns helps you design natural transformation flows. +> "Space and time cannot be defined independently of each other." +> +> —Albert Einstein, The Foundation of the General Theory of Relativity (1916) -## Linear Metamorphic Chain +## Time and Domain Are Inseparable -The simplest pattern: A → B → C → D +Just as Einstein discovered the inseparability of time and space, the Be Framework considers time and domain as a single entity that cannot be divided. Approval processes have their approval time, payments have their payment time, and transformation naturally emerges along the unique temporal axis that each domain logic possesses. + +## Irreversible Flow of Time + +Object metamorphosis follows the arrow of time in a unidirectional flow. There is no returning to the past, no remaining in the same moment: ```php -// Input +// Time T0: Birth of input #[Be(EmailValidation::class)] final class EmailInput { /* ... */ } -// First transformation +// Time T1: First metamorphosis (T0 is already past) #[Be(UserCreation::class)] final class EmailValidation { /* ... */ } -// Second transformation +// Time T2: Second metamorphosis (T1 becomes memory) #[Be(WelcomeMessage::class)] final class UserCreation { /* ... */ } -// Final result +// Time T3: Final existence (encompassing all past) final class WelcomeMessage { /* ... */ } ``` -Each stage naturally leads to the next, like a river flowing to the sea. +Each moment never returns, and new existence preserves previous forms as memory within itself. Like a river flowing, time moves only in one direction. -## Branching Destinies +## Self-Determination of Destiny -Objects can have multiple possible futures based on their nature: +Like living beings in reality, objects determine their own destiny through the interaction between intrinsic nature and external environment. This is not following a predetermined route, but natural metamorphosis responding to the circumstances of that moment: ```php #[Be([ApprovedApplication::class, RejectedApplication::class])] @@ -43,11 +49,12 @@ final class ApplicationReview public readonly ApprovedApplication|RejectedApplication $being; public function __construct( - #[Input] array $documents, // Immanent - #[Inject] ReviewService $reviewer // Transcendent + #[Input] array $documents, // Intrinsic nature + #[Inject] ReviewService $reviewer // External environment ) { $result = $reviewer->evaluate($documents); + // Destiny is decided at this very moment $this->being = $result->isApproved() ? new ApprovedApplication($documents, $result->getScore()) : new RejectedApplication($result->getReasons()); @@ -55,61 +62,7 @@ final class ApplicationReview } ``` -The object determines its own destiny through **Type-Driven Metamorphosis**. - -## Fork-Join Pattern - -A single input branches into parallel transformations that later converge: - -```php -#[Be(PersonalizedRecommendation::class)] -final class UserAnalysis -{ - public readonly PersonalizedRecommendation $being; - - public function __construct( - #[Input] string $userId, // Immanent - #[Inject] BehaviorAnalyzer $behavior, // Transcendent - #[Inject] PreferenceAnalyzer $preference, // Transcendent - #[Inject] SocialAnalyzer $social // Transcendent - ) { - // Parallel analysis - $behaviorScore = $behavior->analyze($userId); - $preferenceScore = $preference->analyze($userId); - $socialScore = $social->analyze($userId); - - // Convergence - $this->being = new PersonalizedRecommendation( - $behaviorScore, - $preferenceScore, - $socialScore - ); - } -} -``` - -## Conditional Transformation - -Sometimes transformation depends on runtime conditions: -```php -#[Be([PremiumFeatures::class, BasicFeatures::class])] -final class FeatureActivation -{ - public readonly PremiumFeatures|BasicFeatures $being; - - public function __construct( - #[Input] User $user, // Immanent - #[Inject] SubscriptionService $service // Transcendent - ) { - $subscription = $service->getSubscription($user); - - $this->being = $subscription->isPremium() - ? new PremiumFeatures($user, $subscription) - : new BasicFeatures($user); - } -} -``` ## Nested Metamorphosis @@ -134,7 +87,26 @@ final class OrderProcessing ## Self-Organizing Pipelines -The beauty of these patterns is that they're **self-organizing**. Objects declare their own destinies, and the framework naturally follows the transformation paths without external orchestration. +The beauty of these patterns is that they're **self-organizing**. Like UNIX pipes that combine simple commands to create powerful systems, Be Framework combines typed objects to create natural transformation flows. + +### Comparison with UNIX Pipes + +```bash +# UNIX: Text flows through externally controlled pipelines +cat access.log | grep "404" | awk '{print $7}' | sort | uniq -c +``` + +```php +// Be Framework: Rich objects flow through intrinsically controlled pipelines +$finalObject = $becoming(new ApplicationInput($documents)); +// Objects themselves know their next transformation destination +``` + +Key evolution: +- **UNIX**: External shell controls the pipeline +- **Be Framework**: Objects declare their own destiny with `#[Be()]` + +### Self-Organization in Action ```php // No controllers, no orchestrators—just natural flow @@ -147,14 +119,77 @@ match (true) { }; ``` -## Pattern Selection +This self-organization provides: +- No external orchestration needed +- Type safety maintained +- Capabilities provided through dependency injection +- Testable independent components + +## Implementation Guidelines + +### When to Choose Linear Metamorphosis + +For sequential processing where each stage prepares the data needed for the next: + +```php +User Registration → Email Verification → Account Activation → Welcome Notification +``` + +This is suitable when failure at any stage should halt the entire process. + +### When to Choose Conditional Branching + +When the same input branches into different results based on nature or permissions: + +```php +// Implementation example: Feature differentiation by payment capability +#[Be([FullAccess::class, LimitedAccess::class, ReadOnlyAccess::class])] +final class AccessDetermination +{ + public readonly FullAccess|LimitedAccess|ReadOnlyAccess $being; + + public function __construct( + #[Input] User $user, + #[Inject] PaymentStatus $payment + ) { + $this->being = match($payment->getStatus()) { + 'premium' => new FullAccess($user, $payment->getFeatures()), + 'basic' => new LimitedAccess($user, $payment->getLimits()), + default => new ReadOnlyAccess($user) + }; + } +} +``` + +### When to Choose Nested Metamorphosis + +When executing multiple independent processes in parallel and aggregating their results: + +```php +final class OrderCompletion +{ + public function __construct( + #[Input] OrderData $order, + #[Inject] Becoming $becoming + ) { + // Independent parallel processing + $this->inventory = $becoming(new InventoryCheck($order->items)); + $this->payment = $becoming(new PaymentProcess($order->payment)); + $this->shipping = $becoming(new ShippingArrange($order->address)); + } +} +``` + +## Design Principles + +Choose metamorphosis patterns according to the natural flow of domain logic: -Choose patterns based on your domain's natural flow: +- **Don't Force**: Don't force into artificial patterns +- **Keep Simple**: Choose the most simple and understandable form +- **Testable**: Each metamorphosis stage can be tested independently +- **Type Safe**: Next type is guaranteed by `#[Be()]` -- **Linear**: Sequential processes (validation → processing → completion) -- **Branching**: Decision points (approve/reject, success/failure) -- **Fork-Join**: Parallel analysis that converges -- **Conditional**: Feature flags, permissions, subscriptions -- **Nested**: Complex operations with sub-processes +Objects govern their own metamorphosis. -The key is to let the transformation emerge naturally from the domain logic, not force it into artificial patterns. +Heraclitus said "the river flows" is not correct, but rather "the flowing is the river." He believed that existence cannot be separated from change. Be Framework likewise believes that to capture essence, domain and time cannot be separated. +Domains are temporal existence. There are possibilities and being at each moment. Capturing how input classes, being classes, and final objects naturally metamorphose along the flow of time is the core of the Be Framework. diff --git a/manuals/1.0/en/12-from-doing-to-being-final.md b/manuals/1.0/en/12-from-doing-to-being-final.md index 37157b0..5c63655 100644 --- a/manuals/1.0/en/12-from-doing-to-being-final.md +++ b/manuals/1.0/en/12-from-doing-to-being-final.md @@ -7,7 +7,11 @@ permalink: /manuals/1.0/en/12-from-doing-to-being-final.html # From Doing to Being: The Bigger Picture -> *"The real voyage of discovery consists not in seeking new landscapes, but in having new eyes."* — Marcel Proust +> "All things that exist are in the process of becoming." +> +> —Heraclitus, Fragments (c. 500 BC) + +## What You Have Discovered You've written Input Classes, created Being Classes, and watched objects transform rather than mutate. diff --git a/manuals/1.0/ja/01-overview.md b/manuals/1.0/ja/01-overview.md index caff87a..5faf23a 100644 --- a/manuals/1.0/ja/01-overview.md +++ b/manuals/1.0/ja/01-overview.md @@ -5,7 +5,11 @@ category: Manual permalink: /manuals/1.0/ja/01-overview.html --- -## 概要: 新しいパラダイム +# 概要 + +> 「真の発見の航海は、新しい風景を求めることではなく、新しい目を持つことにある。」 +> +> 　　—マルセル・プルースト『囚われの女』（À la recherche du temps perdu 第5巻）1923年 ## まず、これを見てください diff --git a/manuals/1.0/ja/02-input-classes.md b/manuals/1.0/ja/02-input-classes.md index 7e3f178..ff08507 100644 --- a/manuals/1.0/ja/02-input-classes.md +++ b/manuals/1.0/ja/02-input-classes.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/ja/02-input-classes.html # 入力クラス +> 「私たちは自分で選択できない条件から始まり、そこから自分の存在を築く」 +> +> 　　—ハイデガーの被投性（Geworfenheit）概念より（『存在と時間』1927年） + +## 出発点 + 入力クラスは、Beフレームワークにおけるすべての変容の出発点です。 ここにはオブジェクト自身が持つ要素だけが含まれ、外部依存がありません。いわばオブジェクトのアイデンティティです。オブジェクトの内側にあるものなので、これを**内在的性質、イマナンス（Immanence）**と呼びます。 diff --git a/manuals/1.0/ja/03-being-classes.md b/manuals/1.0/ja/03-being-classes.md index 0b1d419..423b2e0 100644 --- a/manuals/1.0/ja/03-being-classes.md +++ b/manuals/1.0/ja/03-being-classes.md @@ -7,6 +7,12 @@ permalink: /manuals/1.0/ja/03-being-classes.html # 存在クラス +> 「道常無為而無不為」 +> +> —道は常に無為にして、而も為さざることなし（老子『道徳経』第三十七章　紀元前6世紀） + +## 内在と超越 + 存在クラスは変容が実際に起こる場所です。 オブジェクト自身が持つ性質（**内在的性質（イマナンス）**）と、外部から提供される力（**超越的な力（トランセンデンス）**）が出会い、次の新しい存在が生まれます。入力クラスが「始まり」なら、存在クラスは「変わる瞬間」を表現します。 diff --git a/manuals/1.0/ja/04-final-objects.md b/manuals/1.0/ja/04-final-objects.md index e3f2713..077ee58 100644 --- a/manuals/1.0/ja/04-final-objects.md +++ b/manuals/1.0/ja/04-final-objects.md @@ -7,19 +7,39 @@ permalink: /manuals/1.0/ja/04-final-objects.html # 最終オブジェクト -最終オブジェクトは変容の目的地を表します—ユーザーの実際の関心を体現する、完全で変容した存在です。これらはアプリケーションが最終的に気にかけるものです。 +> 「あなたは私ではない。どうして私が魚の気持ちを知らないと分かるのか？」 +> +> —「あなたは魚ではない。どうして魚の気持ちが分かるのか」と問われた時に荘子が返した言葉 （『荘子』紀元前4世紀） + +## 終着点 + +最終オブジェクトは変容の旅路の到達点です。 +ユーザーが求める価値、アプリケーションが届けたい結果が具現化された、完全で最終的な存在です。 + +これは入力クラスから始まった内在的性質（イマナンス）が、様々な超越的力（トランセンデンス）と出会い、自然な変容を経て達成した最終形態です。アリストテレスの言うエンテレケイア、すなわち潜在性が完全に現実化された状態を体現しています。 ## 最終オブジェクトの特徴 -**完全な存在**: 最終オブジェクトは意図された目的のためにさらなる変容を必要としない、完全に形成されたエンティティです。 +**完全性（エンテレケイア）**: これ以上の変容を必要としない、完全に現実化された存在です。 + +**ユーザー価値の実現**: ユーザーが本当に必要とするもの、意味のあるデータや操作の成功結果を表現します。 + +**豊かな状態**: 入力クラスとは対照的に、最終オブジェクトはドメインの豊富さを完全に表現した存在です。 + +## 時間的存在の完全性 + +ここで興味深い問いがあります。テストが不要になるほどの完全性を持つオブジェクトがあったらどうでしょう？ -**ユーザー中心**: これらはユーザーが実際に欲しいもの—成功した操作、意味のあるデータ、実行可能な結果を表します。 +Be Frameworkでは、オブジェクトの時間的存在を二つの軸で捉えます： -**豊富な状態**: 入力クラスとは異なり、最終オブジェクトは変容されたデータの完全な豊かさを含みます。 +- **`#[Be]`**: なりたい自分、向かう先（未来への方向性） +- **`$been`**: 完了した自分（過去完了の自己証明） + +従来のプログラミングでは、オブジェクトが正しく処理されたかどうかを外部のテストで検証します。しかし、オブジェクト自身が完了の証拠を内包していたらどうでしょう？外部による検証ではなく、内在的な自己証明が可能になります。 ## 例 -### 成功した結果 +### 内在的自己証明を持つ結果 ```php final class SuccessfulOrder { @@ -27,51 +47,79 @@ final class SuccessfulOrder public readonly string $confirmationCode; public readonly DateTimeImmutable $timestamp; public readonly string $message; + public readonly BeenProcessed $been; // 自己証明 public function __construct( - #[Input] Money $total, // 検証からの内在的 - #[Input] CreditCard $card, // 検証からの内在的 - #[Inject] OrderIdGenerator $generator, // 超越的 - #[Inject] Receipt $receipt // 超越的 + #[Input] Money $total, // 内在的性質 + #[Input] CreditCard $card, // 内在的性質 + #[Inject] OrderIdGenerator $generator, // 超越的力 + #[Inject] Receipt $receipt // 超越的力 ) { - $this->orderId = $generator->generate(); // 新しい内在的 - $this->confirmationCode = $receipt->generate($total); // 新しい内在的 - $this->timestamp = new DateTimeImmutable(); // 新しい内在的 - $this->message = "注文確認: {$this->orderId}"; // 新しい内在的 + $this->orderId = $generator->generate(); // 新しい内在的性質 + $this->confirmationCode = $receipt->generate($total); // 新しい内在的性質 + $this->timestamp = new DateTimeImmutable(); // 新しい内在的性質 + $this->message = "注文確認: {$this->orderId}"; // 新しい内在的性質 + + // 完了の自己証明 + $this->been = new BeenProcessed( + actor: $card->getHolderName(), + timestamp: $this->timestamp, + evidence: [ + 'total' => $total->getAmount(), + 'payment_method' => $card->getType(), + 'confirmation' => $this->confirmationCode + ] + ); } } ``` -### 最終オブジェクトとしてのエラー状態 +このオブジェクトは外部テストを必要としません。`$been`プロパティが完了の完全な証拠を内包しているからです。 + +### エラー状態の自己証明 ```php final class FailedOrder { public readonly string $errorCode; public readonly string $message; public readonly DateTimeImmutable $timestamp; + public readonly BeenRejected $been; // 失敗の自己証明 public function __construct( - #[Input] array $errors, // 検証からの内在的 - #[Inject] Logger $logger, // 超越的 - #[Inject] ErrorCodeGenerator $generator // 超越的 + #[Input] array $errors, // 内在的性質 + #[Inject] Logger $logger, // 超越的力 + #[Inject] ErrorCodeGenerator $generator // 超越的力 ) { $this->errorCode = $generator->generate(); $this->message = "注文失敗: " . implode(', ', $errors); $this->timestamp = new DateTimeImmutable(); + // 失敗の自己証明 + $this->been = new BeenRejected( + reason: 'validation_failed', + timestamp: $this->timestamp, + evidence: [ + 'error_count' => count($errors), + 'error_types' => array_keys($errors), + 'error_code' => $this->errorCode + ] + ); + $logger->logOrderFailure($this->errorCode, $errors); // 副作用 } } ``` +成功も失敗も、どちらも完了の自己証明を持ちます。外部テストではなく、オブジェクト自身が何が起こったかの完全な記録を保持しているのです。 + ## 最終オブジェクト vs 入力クラス | 入力クラス | 最終オブジェクト | |-----------|-----------------| -| 純粋なアイデンティティ | 豊富で変容した状態 | -| 出発点 | 目的地 | +| 純粋なアイデンティティ | 豊かで変容した状態 | +| 変容の出発点 | 変容の到達点 | | ユーザーが提供するもの | ユーザーが受け取るもの | -| 単純な構造 | 完全な機能 | +| シンプルな構造 | 完全に実現された機能 | ## 複数の最終的運命 @@ -99,8 +147,12 @@ if ($order->being instanceof SuccessfulOrder) { 2. **存在クラス**: 変容段階（「これが私の変化の仕方です」） 3. **最終オブジェクト**: 完全な結果（「これが私がなったものです」） -ユーザーは主に入力（彼らが提供するもの）と最終オブジェクト（彼らが受け取るもの）に関心を持ちます。間にある存在クラスはフレームワークの責任です—意図と結果の間の橋を作る変容の機械です。 +ユーザーは主に入力（彼らが提供するもの）と最終オブジェクト（彼らが受け取るもの）に関心を持ちます。間にある存在クラスは私たち設計者の責任です。意図と結果の間の橋渡しをするためにドメインの時間的変容をよく理解し、その変容の仕組みを設計することが重要です。 + +## 変容の完成 + +最終オブジェクトは、エンテレケイア（完全実現）の状態を表現します。変容の必要がもうない、完全に実現された存在です。 -## 自然な完成 +入力クラスから始まった内在的性質（イマナンス）が、様々な超越的力（トランセンデンス）と出会いながら自然な変容を経て、ついに到達した完成形です。ここにはもう「なろうとする」努力も、「変わろうとする」意図もありません。すべてが完了し、ユーザーが本当に求めていた価値がここに実現されています。私たちのシステムの本質的な価値です。 -最終オブジェクトは自然な変容の完成を体現します。これらはもう何かを「する」必要がありません—単純に、元の入力が世界の能力と出会うことから生まれることを意図された結果*である*のです。 \ No newline at end of file +これこそが、Be Frameworkが目指すプログラミングの到達点—「何をするか」ではなく「何であるか」が体現された存在です。 diff --git a/manuals/1.0/ja/05-metamorphosis-patterns.md b/manuals/1.0/ja/05-metamorphosis-patterns.md index 543afbc..2a256ba 100644 --- a/manuals/1.0/ja/05-metamorphosis-patterns.md +++ b/manuals/1.0/ja/05-metamorphosis-patterns.md @@ -1,40 +1,46 @@ --- layout: docs-ja -title: "5. 変容パターン" +title: "5. メタモルフォーシス" category: Manual -permalink: /manuals/1.0/ja/05-metamorphosis-patterns.html +permalink: /manuals/1.0/ja/05-metamorphosis.html --- -# 変容パターン +# メタモルフォーシス -Beフレームワークは、単純な線形チェーンから複雑な分岐する運命まで、様々な変容パターンをサポートします。これらのパターンを理解することで、自然な変容フローを設計できます。 +> 「空間と時間は独立に定義できない」 +> +> 　　—アルベルト・アインシュタイン『一般相対性理論の基礎』（1916年） -## 線形変容チェーン +## 時間とドメインは分割できない -最もシンプルなパターン：A → B → C → D +アインシュタインが時間と空間の不可分性を発見したように、Beフレームワークでは時間とドメインは分割できない一つの実体です。承認プロセスには承認の時間が、決済には決済の時間があり、それぞれのドメインロジックが持つ固有の時間軸に沿って変容が自然に現れます。 + +## 不可逆的時間の流れ + +オブジェクトの変容は時間の矢に沿った一方向の流れです。過去に戻ることも、同じ瞬間に留まることもできません： ```php -// 入力 +// 時間 T0: 入力の誕生 #[Be(EmailValidation::class)] final class EmailInput { /* ... */ } -// 第一変容 +// 時間 T1: 第一変容（T0は既に過去） #[Be(UserCreation::class)] final class EmailValidation { /* ... */ } -// 第二変容 +// 時間 T2: 第二変容（T1は記憶となる） #[Be(WelcomeMessage::class)] final class UserCreation { /* ... */ } -// 最終結果 +// 時間 T3: 最終存在（すべての過去を内包） final class WelcomeMessage { /* ... */ } ``` -各段階は自然に次へと導かれ、川が海に流れるようです。 +各瞬間は二度と戻らず、新しい存在は前の形態をその内部に記憶として保持します。川が流れるように、時間は一方向にのみ流れます。 -## 分岐する運命 +## 運命の自己決定 -オブジェクトはその性質に基づいて複数の可能な未来を持つことができます： +現実の生物と同様に、オブジェクトは内在的な性質と外部環境の相互作用によって、自身の運命を決定します。これは予め決められたルートを辿るのではなく、その瞬間の状況に応じた自然な変容です： ```php #[Be([ApprovedApplication::class, RejectedApplication::class])] @@ -43,11 +49,12 @@ final class ApplicationReview public readonly ApprovedApplication|RejectedApplication $being; public function __construct( - #[Input] array $documents, // 内在的 - #[Inject] ReviewService $reviewer // 超越的 + #[Input] array $documents, // 内在的性質 + #[Inject] ReviewService $reviewer // 外部環境 ) { $result = $reviewer->evaluate($documents); + // 運命は今この瞬間に決まる $this->being = $result->isApproved() ? new ApprovedApplication($documents, $result->getScore()) : new RejectedApplication($result->getReasons()); @@ -55,106 +62,136 @@ final class ApplicationReview } ``` -オブジェクトは**型駆動変容**を通して自身の運命を決定します。 -## フォーク・ジョインパターン +## ネストした変容 -単一の入力が並列変容に分岐し、後に収束します： +複雑なオブジェクトは独自の変容チェーンを含むことができます： ```php -#[Be(PersonalizedRecommendation::class)] -final class UserAnalysis +final class OrderProcessing { - public readonly PersonalizedRecommendation $being; + public readonly PaymentResult $payment; + public readonly ShippingResult $shipping; public function __construct( - #[Input] string $userId, // 内在的 - #[Inject] BehaviorAnalyzer $behavior, // 超越的 - #[Inject] PreferenceAnalyzer $preference, // 超越的 - #[Inject] SocialAnalyzer $social // 超越的 + #[Input] Order $order, // 内在的 + #[Inject] Becoming $becoming // 超越的 ) { - // 並列分析 - $behaviorScore = $behavior->analyze($userId); - $preferenceScore = $preference->analyze($userId); - $socialScore = $social->analyze($userId); - - // 収束 - $this->being = new PersonalizedRecommendation( - $behaviorScore, - $preferenceScore, - $socialScore - ); + // ネストした変容 + $this->payment = $becoming(new PaymentInput($order->getPayment())); + $this->shipping = $becoming(new ShippingInput($order->getAddress())); } } ``` -## 条件付き変容 +## 自己組織化パイプライン + +これらのパターンの美しさは、それらが**自己組織化**であることです。Unixパイプが単純なコマンドを組み合わせて強力なシステムを作るように、Beフレームワークは型付きオブジェクトを組み合わせて自然な変容の流れを作ります。 + +### Unixパイプとの比較 + +```bash +# Unix: テキストが流れる外部制御のパイプライン +cat access.log | grep "404" | awk '{print $7}' | sort | uniq -c +``` + +```php +// Be Framework: リッチなオブジェクトが流れる内在的制御のパイプライン +$finalObject = $becoming(new ApplicationInput($documents)); +// オブジェクト自身が次の変容先を知っている +``` + +重要な進化： +- **Unix**: 外部のshellがパイプを制御 +- **Be Framework**: オブジェクト自身が`#[Be()]`で運命を宣言 + +### 自己組織化の実現 + +```php +// コントローラーもオーケストレーターもなし—ただ自然な流れ +$finalObject = $becoming(new ApplicationInput($documents)); + +// オブジェクトはあるべき姿になりました +match (true) { + $finalObject->being instanceof ApprovedApplication => $this->sendApprovalEmail($finalObject->being), + $finalObject->being instanceof RejectedApplication => $this->sendRejectionEmail($finalObject->being), +}; +``` + +この自己組織化により： +- 外部オーケストレーションが不要 +- 型安全性が保たれる +- 依存性注入による能力の提供 +- テスト可能な独立したコンポーネント + +## 実装上の選択指針 + +### いつ線形変容を選ぶか -時として変容はランタイム条件に依存します： +シーケンシャルな処理で、各段階が次に必要なデータを準備する場合： ```php -#[Be([PremiumFeatures::class, BasicFeatures::class])] -final class FeatureActivation +ユーザー登録 → メール検証 → アカウント有効化 → ウェルカム通知 +``` + +各段階での失敗は全体を停止させる必要がある場合に適しています。 + +### いつ条件分岐を選ぶか + +同じ入力から性質や権限によって異なる結果に分岐する場合： + +```php +// 実装例：支払い能力による機能差 +#[Be([FullAccess::class, LimitedAccess::class, ReadOnlyAccess::class])] +final class AccessDetermination { - public readonly PremiumFeatures|BasicFeatures $being; + public readonly FullAccess|LimitedAccess|ReadOnlyAccess $being; public function __construct( - #[Input] User $user, // 内在的 - #[Inject] SubscriptionService $service // 超越的 + #[Input] User $user, + #[Inject] PaymentStatus $payment ) { - $subscription = $service->getSubscription($user); - - $this->being = $subscription->isPremium() - ? new PremiumFeatures($user, $subscription) - : new BasicFeatures($user); + $this->being = match($payment->getStatus()) { + 'premium' => new FullAccess($user, $payment->getFeatures()), + 'basic' => new LimitedAccess($user, $payment->getLimits()), + default => new ReadOnlyAccess($user) + }; } } ``` -## ネストした変容 +### いつネストした変容を選ぶか -複雑なオブジェクトは独自の変容チェーンを含むことができます： +複数の独立した処理を並行して実行し、それぞれの結果を集約する場合： ```php -final class OrderProcessing +final class OrderCompletion { - public readonly PaymentResult $payment; - public readonly ShippingResult $shipping; - public function __construct( - #[Input] Order $order, // 内在的 - #[Inject] Becoming $becoming // 超越的 + #[Input] OrderData $order, + #[Inject] Becoming $becoming ) { - // ネストした変容 - $this->payment = $becoming(new PaymentInput($order->getPayment())); - $this->shipping = $becoming(new ShippingInput($order->getAddress())); + // 独立した処理を並行実行 + $this->inventory = $becoming(new InventoryCheck($order->items)); + $this->payment = $becoming(new PaymentProcess($order->payment)); + $this->shipping = $becoming(new ShippingArrange($order->address)); } } ``` -## 自己組織化パイプライン +## 設計原則 -これらのパターンの美しさは、それらが**自己組織化**であることです。オブジェクトは自身の運命を宣言し、フレームワークは外部のオーケストレーションなしに自然に変容パスに従います。 +変容パターンの選択は、ドメインロジックの自然な流れに従ってください： -```php -// コントローラーもオーケストレーターもなし—ただ自然な流れ -$finalObject = $becoming(new ApplicationInput($documents)); +- **強制しない**: 人工的なパターンに無理やり当てはめない +- **シンプルに**: 最も単純で理解しやすい形を選ぶ +- **テスト可能**: 各変容段階が独立してテストできる +- **型安全**: `#[Be()]` によって次の型が保証される -// オブジェクトはあるべき姿になりました -match (true) { - $finalObject->being instanceof ApprovedApplication => $this->sendApprovalEmail($finalObject->being), - $finalObject->being instanceof RejectedApplication => $this->sendRejectionEmail($finalObject->being), -}; -``` +オブジェクトは自らが自らの変容を規定します。 -## パターンの選択 +ヘラクレイトスは『川が流れている』のではなく『流れているのが川だ』と言いました。存在は変化とは切り離せないと考えたのです。Be Frameworkも同じように本質を捉えるためにはドメインと時間は切り離せないものと考えました。 +ドメインは時間的存在です。その時その時の可能性と存在があります。入力クラス、存在クラス、最終オブジェクトが時間の流れに沿って自然に変容していく様を捉えることが、Beフレームワークの核心です。 -ドメインの自然な流れに基づいてパターンを選択してください： -- **線形**: 順次プロセス（検証 → 処理 → 完了） -- **分岐**: 決定ポイント（承認/拒否、成功/失敗） -- **フォーク・ジョイン**: 収束する並列分析 -- **条件付き**: 機能フラグ、権限、サブスクリプション -- **ネストした**: サブプロセスを持つ複雑な操作 -重要なのは、変容をドメインロジックから自然に生まれさせることであり、人工的なパターンに強制することではありません。 \ No newline at end of file diff --git a/manuals/1.0/ja/12-from-doing-to-being-final.md b/manuals/1.0/ja/12-from-doing-to-being-final.md index a915665..958f410 100644 --- a/manuals/1.0/ja/12-from-doing-to-being-final.md +++ b/manuals/1.0/ja/12-from-doing-to-being-final.md @@ -7,7 +7,11 @@ permalink: /manuals/1.0/ja/12-from-doing-to-being-final.html # Doingから Beingへ: より大きな視点 -> *「真の発見の航海は、新しい風景を求めることではなく、新しい目を持つことにある。」* — マルセル・プルースト +> 「存在するものは全て生成の途上にある」 +> +> 　　—ヘラクレイトス『断片』（紀元前500年頃） + +## あなたが発見したもの あなたは入力クラスを書き、存在クラスを作成し、オブジェクトが変異するのではなく変容するのを見てきました。