Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion manuals/1.0/en/01-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
6 changes: 6 additions & 0 deletions manuals/1.0/en/02-input-classes.md
Original file line number Diff line number Diff line change
Expand Up @@ -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**.
Expand Down
6 changes: 6 additions & 0 deletions manuals/1.0/en/03-being-classes.md
Original file line number Diff line number Diff line change
Expand Up @@ -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."
Expand Down
81 changes: 65 additions & 16 deletions manuals/1.0/en/04-final-objects.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -17,53 +23,92 @@ 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
{
public readonly string $orderId;
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 |
Expand Down Expand Up @@ -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."
6 changes: 5 additions & 1 deletion manuals/1.0/en/12-from-doing-to-being-final.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
6 changes: 5 additions & 1 deletion manuals/1.0/ja/01-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,11 @@ category: Manual
permalink: /manuals/1.0/ja/01-overview.html
---

## 概要: 新しいパラダイム
# 概要

> 「真の発見の航海は、新しい風景を求めることではなく、新しい目を持つことにある。」
>
>   —マルセル・プルースト『囚われの女』(À la recherche du temps perdu 第5巻)1923年

## まず、これを見てください

Expand Down
6 changes: 6 additions & 0 deletions manuals/1.0/ja/02-input-classes.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,12 @@ permalink: /manuals/1.0/ja/02-input-classes.html

# 入力クラス

> 「私たちは自分で選択できない条件から始まり、そこから自分の存在を築く」
>
>   —ハイデガーの被投性(Geworfenheit)概念より(『存在と時間』1927年)

## 出発点

入力クラスは、Beフレームワークにおけるすべての変容の出発点です。

ここにはオブジェクト自身が持つ要素だけが含まれ、外部依存がありません。いわばオブジェクトのアイデンティティです。オブジェクトの内側にあるものなので、これを**内在的性質、イマナンス(Immanence)**と呼びます。
Expand Down
6 changes: 6 additions & 0 deletions manuals/1.0/ja/03-being-classes.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,12 @@ permalink: /manuals/1.0/ja/03-being-classes.html

# 存在クラス

> 「道常無為而無不為」
>
> —道は常に無為にして、而も為さざることなし(老子『道徳経』第三十七章 紀元前6世紀)

## 内在と超越

存在クラスは変容が実際に起こる場所です。

オブジェクト自身が持つ性質(**内在的性質(イマナンス)**)と、外部から提供される力(**超越的な力(トランセンデンス)**)が出会い、次の新しい存在が生まれます。入力クラスが「始まり」なら、存在クラスは「変わる瞬間」を表現します。
Expand Down
98 changes: 75 additions & 23 deletions manuals/1.0/ja/04-final-objects.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,71 +7,119 @@ permalink: /manuals/1.0/ja/04-final-objects.html

# 最終オブジェクト

最終オブジェクトは変容の目的地を表します—ユーザーの実際の関心を体現する、完全で変容した存在です。これらはアプリケーションが最終的に気にかけるものです。
> 「あなたは私ではない。どうして私が魚の気持ちを知らないと分かるのか?」
>
> —「あなたは魚ではない。どうして魚の気持ちが分かるのか」と問われた時に荘子が返した言葉 (『荘子』紀元前4世紀)

## 終着点

最終オブジェクトは変容の旅路の到達点です。
ユーザーが求める価値、アプリケーションが届けたい結果が具現化された、完全で最終的な存在です。

これは入力クラスから始まった内在的性質(イマナンス)が、様々な超越的力(トランセンデンス)と出会い、自然な変容を経て達成した最終形態です。アリストテレスの言うエンテレケイア、すなわち潜在性が完全に現実化された状態を体現しています。

## 最終オブジェクトの特徴

**完全な存在**: 最終オブジェクトは意図された目的のためにさらなる変容を必要としない、完全に形成されたエンティティです。
**完全性(エンテレケイア)**: これ以上の変容を必要としない、完全に現実化された存在です。

**ユーザー価値の実現**: ユーザーが本当に必要とするもの、意味のあるデータや操作の成功結果を表現します。

**豊かな状態**: 入力クラスとは対照的に、最終オブジェクトはドメインの豊富さを完全に表現した存在です。

## 時間的存在の完全性

ここで興味深い問いがあります。テストが不要になるほどの完全性を持つオブジェクトがあったらどうでしょう?

**ユーザー中心**: これらはユーザーが実際に欲しいもの—成功した操作、意味のあるデータ、実行可能な結果を表します。
Be Frameworkでは、オブジェクトの時間的存在を二つの軸で捉えます:

**豊富な状態**: 入力クラスとは異なり、最終オブジェクトは変容されたデータの完全な豊かさを含みます。
- **`#[Be]`**: なりたい自分、向かう先(未来への方向性)
- **`$been`**: 完了した自分(過去完了の自己証明)

従来のプログラミングでは、オブジェクトが正しく処理されたかどうかを外部のテストで検証します。しかし、オブジェクト自身が完了の証拠を内包していたらどうでしょう?外部による検証ではなく、内在的な自己証明が可能になります。

## 例

### 成功した結果
### 内在的自己証明を持つ結果
```php
final class SuccessfulOrder
{
public readonly string $orderId;
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 入力クラス

| 入力クラス | 最終オブジェクト |
|-----------|-----------------|
| 純粋なアイデンティティ | 豊富で変容した状態 |
| 出発点 | 目的地 |
| 純粋なアイデンティティ | 豊かで変容した状態 |
| 変容の出発点 | 変容の到達点 |
| ユーザーが提供するもの | ユーザーが受け取るもの |
| 単純な構造 | 完全な機能 |
| シンプルな構造 | 完全に実現された機能 |

## 複数の最終的運命

Expand Down Expand Up @@ -99,8 +147,12 @@ if ($order->being instanceof SuccessfulOrder) {
2. **存在クラス**: 変容段階(「これが私の変化の仕方です」)
3. **最終オブジェクト**: 完全な結果(「これが私がなったものです」)

ユーザーは主に入力(彼らが提供するもの)と最終オブジェクト(彼らが受け取るもの)に関心を持ちます。間にある存在クラスはフレームワークの責任です—意図と結果の間の橋を作る変容の機械です。
ユーザーは主に入力(彼らが提供するもの)と最終オブジェクト(彼らが受け取るもの)に関心を持ちます。間にある存在クラスは私たち設計者の責任です。意図と結果の間の橋渡しをするためにドメインの時間的変容をよく理解し、その変容の仕組みを設計することが重要です。

## 変容の完成

最終オブジェクトは、エンテレケイア(完全実現)の状態を表現します。変容の必要がもうない、完全に実現された存在です。

## 自然な完成
入力クラスから始まった内在的性質(イマナンス)が、様々な超越的力(トランセンデンス)と出会いながら自然な変容を経て、ついに到達した完成形です。ここにはもう「なろうとする」努力も、「変わろうとする」意図もありません。すべてが完了し、ユーザーが本当に求めていた価値がここに実現されています。私たちのシステムの本質的な価値です。

最終オブジェクトは自然な変容の完成を体現します。これらはもう何かを「する」必要がありません—単純に、元の入力が世界の能力と出会うことから生まれることを意図された結果*である*のです。
これこそが、Be Frameworkが目指すプログラミングの到達点—「何をするか」ではなく「何であるか」が体現された存在です。
Loading