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
238 changes: 138 additions & 100 deletions README.ja.md
Original file line number Diff line number Diff line change
@@ -1,160 +1,198 @@
# BE Framework デモ集
# Be Framework パターン集

BE Frameworkの存在論的プログラミングアプローチを示すデモプロジェクト集です。
[Be Framework](https://github.com/be-framework/be) のための**変容(メタモルフォーシス)パターンカタログ**です。8つの実行可能なPHPデモを収録し、それぞれが1つのフロー形状を独立して示しているため、自分のアプリケーションの出発点としてそのままコピーできます。

## 哲学
> **「Be, Don't Do(するな、あれ)」** — すべてのパターンは、ワークフローを「データに対して動作するメソッド」ではなく、「次の状態へと *becoming* する型付き・不変な状態の連鎖」としてモデル化します。

BE Frameworkは「Be, Don't Do(するな、あれ)」の原則を体現しています。ソフトウェアを動作の連続ではなく、存在の変容(メタモルフォーシス)としてモデル化します。各デモは6つの哲学的レイヤーを通じて異なる変容パターンを示します:
---

| レイヤー | 語源 | 役割 |
|---------|------|------|
| **Input** | δύναμις(デュナミス) | システムに入る生の可能態 |
| **Being** | Dasein(現存在) | 計算されたプロパティを持つ存在状態 |
| **Moment** | 契機 | 遅延Potentialを持つ過渡的段階 |
| **Final** | ἐνέργεια(エネルゲイア) | 完全に現実化された結果 |
| **Semantic** | Sinn(意味) | ドメイン検証ルール |
| **Reason** | 充足理由律 | ビジネスロジックと外部連携 |
## パターンを選ぶ

## デモカタログ
あなたの問題に最も近い行を選んでください。各リンクから完全な実装(テスト付き)に飛べます。

### 初級
| こんな問題には… | パターン | デモ |
|---|---|---|
| 入力1、出力1、中間状態なし | **最小変換** | [hello-world](./demos/hello-world/) |
| 単一フォームの検証と正規化 | **線形** | [contact-form](./demos/contact-form/) |
| 順序のある複数の変換 | **連鎖チェーン** | [user-registration](./demos/user-registration/) |
| 独立した関心事が注入Momentを通じてFinalで収束 | **ダイヤモンド** | [order-processing](./demos/order-processing/) |
| 1つのBeingが複数Reasonサービスをオーケストレーション | **マルチReason Being** | [blog-publishing](./demos/blog-publishing/) |
| 1入力から判定で複数結果に分岐 | **分岐** | [medical-triage](./demos/medical-triage/) |
| 段階的なMoment実現(ステージ1がステージ2のゲート) | **カスケードダイヤモンド** | [loan-application](./demos/loan-application/) |
| 複数入力が複数Finalに分岐し、Momentを共有 | **複合収束** | [insurance-claim](./demos/insurance-claim/) |

#### [hello-world](./demos/hello-world/)
**パターン:** 最小変換
**フロー:** `Input → Final`
> このカタログの機械可読版は [`docs/patterns.json`](./docs/patterns.json) にあります。
>
> **図の凡例**: 実線矢印(`→`)は `#[Be]` による変換チェーン。破線矢印(`⇢`)は `#[Inject]` で Final に注入される Moment を表し、各 Moment は Final のコンストラクタ内で自己完結(`be()`)します。

---

## パターンカタログ

最もシンプルなBE Frameworkデモ。BeingやMomentレイヤーを持たない挨拶変換です。
### 最小変換 — [hello-world](./demos/hello-world/)

```text
HelloInput → Hello
**フロー:** `Input → Final`

```mermaid
flowchart LR
I([Input]) --> F([Final])
```

#### [contact-form](./demos/contact-form/)
**パターン:** 線形変換
**フロー:** `Input → Being → Final`
最もシンプルなBe Frameworkデモ。BeingやMomentレイヤーを持たない挨拶変換です。

> 具体: `HelloInput → Hello`

最もシンプルなBE Frameworkパターン。基本的な入力検証、メール正規化、受領証生成を示すお問い合わせフォームです。
### 線形 — [contact-form](./demos/contact-form/)

```text
ContactInput → EmailNormalized → ContactReceived
**フロー:** `Input → Being → Final`

```mermaid
flowchart LR
I([Input]) --> B([Being]) --> F([Final])
```

#### [user-registration](./demos/user-registration/)
**パターン:** 連鎖チェーン
**フロー:** `Input → Being(A) → Being(B) → Being(C) → Final`
基本的な入力検証、メール正規化、受領証生成を示すお問い合わせフォームです。

Being変換を連鎖させたユーザー登録:メール検証、パスワードハッシュ化、プロフィール拡充。
> 具体: `ContactInput → EmailNormalized → ContactReceived`

### 連鎖チェーン — [user-registration](./demos/user-registration/)

**フロー:** `Input → Being(A) → Being(B) → Being(C) → Final`

```text
RegistrationInput → EmailVerified → PasswordHashed → ProfileEnriched → UserRegistered
```mermaid
flowchart LR
I([Input]) --> B1([Being]) --> B2([Being]) --> B3([Being]) --> F([Final])
```

### 中級
Being変換を連鎖させたユーザー登録:メール検証、パスワードハッシュ化、プロフィール拡充。

> 具体: `RegistrationInput → EmailVerified → PasswordHashed → ProfileEnriched → UserRegistered`

#### [order-processing](./demos/order-processing/)
**パターン:** ダイヤモンドメタモルフォーシス
**フロー:** `Input → [並列Beings] → [並列Moments] → Final`
### ダイヤモンド — [order-processing](./demos/order-processing/)

並列Beingチェーン(在庫、決済、配送)がMomentを生成し、Final状態で収束するECオーダー処理。
**フロー:** `Input → Final`(3つのMomentがFinalに注入される)

```text
OrderInput ─┬→ StockLocated → QuantityChecked → InventoryReserved ─┬→ OrderConfirmed
├→ CardValidated → PaymentAuthorized → PaymentCompleted ─┤
└→ AddressValidated → CarrierSelected → ShippingArranged ─┘
```mermaid
flowchart LR
I([Input]) --> F([Final])
M1([Moment]) -.-> F
M2([Moment]) -.-> F
M3([Moment]) -.-> F
```

#### [blog-publishing](./demos/blog-publishing/)
**パターン:** 連鎖変換(3 Being、2 Moment)
**フロー:** `Input → Moment → Being → Being → Moment → Being → Final`
ECオーダー処理。`OrderInput` は直接 `OrderConfirmed` に遷移し、`OrderConfirmed` が3つの独立した Moment(`InventoryReserved`、`PaymentCompleted`、`ShippingArranged`)を `#[Inject]` します。各 Moment の `be()` は `OrderConfirmed` のコンストラクタ内で呼び出され、3つの関心事が1点で自己完結する「ダイヤモンドメタモルフォーシス」を形成します。

マークダウンレンダリング、スラグ生成、抜粋抽出、著者解決を段階的に処理する記事公開デモ。BeingクラスはArticlePrepared、MarkdownRendered、SlugGenerated。MomentクラスはContentPreparedとMetadataResolved。
> 具体: `OrderInput → OrderConfirmed`(Final に `InventoryReserved`・`PaymentCompleted`・`ShippingArranged` を注入)

```text
ArticleInput → ContentPrepared → ArticlePrepared → MarkdownRendered → MetadataResolved → SlugGenerated → ArticlePublished
### マルチReason Being — [blog-publishing](./demos/blog-publishing/)

**フロー:** `Input → Being → Final`

```mermaid
flowchart LR
I([Input]) --> B([Being]) --> F([Final])
```

### 上級
記事公開デモ。外形的には Linear と同じ `ArticleInput → ArticlePrepared → ArticlePublished` です。特徴は中間 Being(`ArticlePrepared`)が複数の Reason サービス(`MarkdownRenderer`、`SlugGenerator`、`ExcerptExtractor`、`AuthorResolver`)をオーケストレーションし、マークダウンレンダリング・スラグ生成・抜粋抽出・著者解決を1つの変換の中でまとめて行う点にあります。

> 具体: `ArticleInput → ArticlePrepared → ArticlePublished`

### 分岐 — [medical-triage](./demos/medical-triage/)

#### [medical-triage](./demos/medical-triage/)
**パターン:** 分岐メタモルフォーシス
**フロー:** `Input → Being → [分岐] → Final(A) | Final(B) | Final(C)`

```mermaid
flowchart LR
I([Input]) --> B([Being])
B --> F1([Final A])
B --> F2([Final B])
B --> F3([Final C])
```

JTASプロトコルを実装した救急トリアージ。1つの入力が型付き`$being`識別子を通じて3つの異なるFinalに分岐し、各分岐の振る舞いはReason戦略クラスが保持します。

```text
PatientInput → TriageLevelDetermined
│
┌──────────────┼──────────────┐
↓ ↓ ↓
[ImmediateCase] [UrgentCase] [NonUrgentCase]
↓ ↓ ↓
EmergencyAdmitted UrgentQueued OutpatientReferred
> 具体:
> ```text
> PatientInput → TriageLevelDetermined
> │
> ┌──────────────┼──────────────┐
> ↓ ↓ ↓
> [ImmediateCase] [UrgentCase] [NonUrgentCase]
> ↓ ↓ ↓
> EmergencyAdmitted UrgentQueued OutpatientReferred
> ```

### カスケードダイヤモンド — [loan-application](./demos/loan-application/)

**フロー:** `Input → Final`(2つのMomentがFinalに注入され、段階的に実現される)

```mermaid
flowchart LR
I([Input]) --> F([Final])
M1([Moment · ステージ1]) -.-> F
M2([Moment · ステージ2]) -.-> F
```

#### [loan-application](./demos/loan-application/)
**パターン:** カスケードダイヤモンド(2段階)
**フロー:** `Input → Stage1(並列 → 収束) → Stage2(並列 → Final)`
住宅ローン申請デモ。`LoanInput` は直接 `LoanApproved` に遷移し、`LoanApproved` が `CollateralValued` と `InsurancePrepared` を注入します。「カスケード」は Moment 内部の Potential にあり、ステージ1の関心事(身元確認・信用・所得)がステージ2の関心事(物件評価・保険)より先に実現されなければならない点を指します。両ステージは1つの Final に収束します。

段階的Moment実現を伴う住宅ローン申請。Stage 1のMomentは適格性確認時に実現、Stage 2のMomentは最終承認時に実現。
> 具体: `LoanInput → LoanApproved`(Final に `CollateralValued`・`InsurancePrepared` を注入)

```text
LoanInput → IdentityVerified ─┬→ CreditScored → CreditApproved ─┬→ EligibilityConfirmed
└→ IncomeAssessed → IncomeApproved ─┘
↓
┌→ PropertyAppraised → CollateralValued ─┬→ LoanApproved
└→ InsuranceQuoted → InsurancePrepared ─┘
```

#### [insurance-claim](./demos/insurance-claim/)
**パターン:** 複合収束
**フロー:** `Input(A) + Input(B) → 収束 → 並列(3) → 分岐 → Final(A) | Final(B)`
### 複合収束 — [insurance-claim](./demos/insurance-claim/)

複数入力の収束、3方向並列評価、分岐Finalを持つ保険請求処理。
**フロー:** 2つの Input が、共有 Moment を注入された 2つの Final のいずれかに分岐する

```text
ClaimInput ──┬→ ClaimRegistered ─┬→ ClaimValidated ─┬→ DamageAssessed ─┬→ [閾値判定] → ClaimSettled
PolicyInput ─┴→ PolicyVerified ─┘ ├→ AdjusterAssigned ─┤ または
└→ FraudScreened ─┘ ClaimEscalated
```mermaid
flowchart LR
I1([Input A]) --> F1([Final A])
I1 --> F2([Final B])
I2([Input B]) --> F1
I2 --> F2
M1([Moment]) -.-> F1 & F2
M2([Moment]) -.-> F1 & F2
M3([Moment]) -.-> F1 & F2
```

## パターン一覧
保険請求処理デモ。`ClaimInput` と `PolicyInput` はどちらも `#[Be([ClaimSettled, ClaimEscalated])]` を宣言しており、`$being` の型マッチングによって各 Input がちょうど1つの Final に解決されます。`DamageValued`、`AdjustmentReviewed`、`FraudCleared` などの Moment は両方の Final に注入されるため、どちらの分岐を辿っても同じ自己完結ロジックが共有されます。

| パターン | デモ | 入力数 | Being数 | Moment数 | Final数 |
|---------|------|--------|---------|----------|---------|
| 最小 | hello-world | 1 | 0 | 0 | 1 |
| 線形 | contact-form | 1 | 1 | 0 | 1 |
| 連鎖 | user-registration | 1 | 3 | 0 | 1 |
| ダイヤモンド | order-processing | 1 | 6 | 6 | 1 |
| 連鎖 | blog-publishing | 1 | 3 | 2 | 1 |
| 分岐 | medical-triage | 1 | 1 | 0 | 3 |
| カスケード | loan-application | 1 | 5 | 4 | 1 |
| 複合 | insurance-claim | 2 | 5 | 3 | 2 |
> 具体: `ClaimInput` + `PolicyInput` → `ClaimSettled` または `ClaimEscalated`(各 Final に共有 Moment を注入)

## テスト実行
---

各デモには以下をカバーする包括的なテストが含まれます:
- 正常系統合テスト
- Semantic検証単体テスト
- Reasonレイヤーロジックテスト
- Potential冪等性テスト(該当する場合)
## テスト実行

```bash
# 全テスト実行
composer test

# 特定デモのテスト実行
./demos/vendor/bin/phpunit demos/medical-triage/tests/
cd demos/hello-world && composer install && vendor/bin/phpunit
```

各デモには正常系統合テスト、Semantic検証単体テスト、Reasonレイヤーロジックテスト、そして該当する場合はPotential冪等性テストが含まれます。

## 要件

- PHP 8.2+
- [Ray.Di](https://ray-di.github.io/)(依存性注入)

## 背景

上記のすべてのパターンは、同じ6つのレイヤーからなる語彙で構築されています。パターンをコピーして使うだけならこの語彙を理解する必要は**ありません**。さらに深く学びたい場合は以下から:

- [`CLAUDE.md`](./CLAUDE.md) — 不変条件と読み順(AIアシスタント向けの契約でもあります)
- [`docs/GLOSSARY.md`](./docs/GLOSSARY.md) — 用語→ファイル逆引きインデックス
- [`demos/order-processing/docs/PHILOSOPHY.md`](./demos/order-processing/docs/PHILOSOPHY.md) — 概念的な理論的背景

| レイヤー | 語源 | 役割 |
|---|---|---|
| **Input** | δύναμις(デュナミス) | システムに入る生の可能態 |
| **Being** | Dasein(現存在) | 計算されたプロパティを持つ存在状態 |
| **Moment** | 契機 | 遅延Potentialを持つ過渡的段階 |
| **Final** | ἐνέργεια(エネルゲイア) | 完全に現実化された結果 |
| **Semantic** | Sinn(意味) | ドメイン検証ルール |
| **Reason** | 充足理由律 | ビジネスロジックと外部連携 |

## ライセンス

MIT

---

[English version](./README.md)
[English version](./README.md)
Loading
Loading