Be Framework FAQ

最終更新: 2025-09-13

0) 要旨（TL;DR）

Q. これは新しい”プログラミングパラダイム”ですか？

A. はい。Be Frameworkは、 時間的存在を一次市民に据え、「何をするか」ではなく「何であるか」に基づいて設計します。

思想面では大きなパラダイム転換ですが、実装面ではOOP/FP/DDDと共存可能で、既存スタイルを置き換える必要はありません。

1) パラダイム & 概念

Q1. MVCやDDDとどう違いますか？

A. MVCは責務分割の構造パターン、DDDはモデリングの方法論です。

Be Frameworkは「存在条件と時間的変容」を中核に据える設計パラダイムで、#[Be]と$beingによりフローが自己組織化されます。

Q2. OOP/FPのどちらですか？

A. どちらの要素もあります。

不変性・参照透明性を重視しながら、コンストラクタでの一回完結の変容（エンテレケイア）をOOPの枠組みで実現しています。

Q3. 「BEING（何であるか）」を先に定義する利点は？

A. 不正状態を事前に生成不能にできます。

防御的なif/guard文が激減し、型＝到達可能状態がAPI仕様となります。

Q4. 「時間的存在の型」とは何ですか？

A. ValidatedUser、SavedUser、DeletedUserなど、進行中の特定の時を型名で表現しています。

Be Frameworkは時間とドメインは不可分と考えます。詳細は変容をご覧ください。

2) 主要機能

Q5. #[Be]属性は何をしますか？

A. オブジェクトの運命（次に何になるか）を宣言します。

単一または複数の変容候補を指定し、実行時に$beingプロパティの型で継続先が自動選択されます。

詳しくは型駆動変容をご参照ください。

Q6. $beingプロパティの役割は何ですか？

A. 現在の存在が導く次の存在を保持します。

ユニオン型を使用することで、結果の全可能性を明示しています。

Q6.5. $beingや$beenは特別なプロパティですか？

A. いいえ、特別なプロパティではありません。

これらはフレームワークが魔法的に解釈するものではなく、単なる規約です。

becoming()関数はプロパティ名を読むのではなく、プロパティに宣言された型を見て次のクラスを選択します。

そのため、$beingや$beenという名前である必要はありません。public Success|Failure $result;のように別の名前でも同じように動作します。

ただし、ドキュメント・サンプル・設計思想に合わせてこの名前を使用することで、「変容先（being）」「完了の証跡（been）」が一目で分かるというメリットがあります。

Q7. 変容の連鎖はどのように制御されますか？

A. #[Be]属性の連鎖により、自動的に次の変容が決定されます。

複数の変容先が可能な場合は、$beingプロパティのユニオン型で表現し、実際に代入された型によって次の変容先が決まります。この仕組みにより、複雑なビジネスロジックも宣言的に表現できます。

Q8. 「意味変数」とは何ですか？

A. 変数名＝意味＋制約です。$emailは「有効なEmail」でなければ存在できません。

分散しがちな検証（controller/validator/docs）を型に統合します。

（詳細：意味変数）

Q8.5. 意味は違うが制約が同じ変数（$userId、$authorIdなど）はどう扱いますか？

A. 共通の基底クラスやトレイトで制約を共有し、継承で意味を分離します。

// src/Semantic/Abstract/Id.php - 共通制約を持つ基底クラス
namespace App\Semantic\Abstract;

abstract readonly class Id {
    public function __construct(public string $value) {
        if (!preg_match('/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}/', $value)) {
            throw new InvalidIdException();
        }
    }
}

// src/Semantic/UserId.php - 意味変数として継承
readonly class UserId extends \App\Semantic\Abstract\Id {}
readonly class AuthorId extends \App\Semantic\Abstract\Id {}

// 使用例：変数名に意味が込められる
function updateArticle(UserId $userId, AuthorId $authorId) {
    // $userIdと$authorIdは混同不可能
}

Q9. 「存在理由層（Reason）」とは何ですか？

A. ある存在状態を成立させる根拠＝道具一式をオブジェクトとして注入します。

従来の個別DIを意味で束ねてテスト容易性を高めます。

（詳細：存在理由層）

Q10. $been（自己証明）は何のためですか？

A. その存在が完了した証跡（誰が・いつ・何を）を内在させます。

外部テストや監査ログと整合しやすくなります。

（詳細：最終オブジェクト）

3) 設計・実装

Q11. どこで副作用を起こしますか？

A. 原則としてコンストラクタの中でReasonに委譲して完結させます。

外部オーケストレーターや巨大なservice層を不要にします。

Q12. 例外はどう扱いますか？

A. 意味的例外を用いて、失敗を集合で保持します（多言語メッセージ対応）。

「部分成功・部分失敗」もInvalid〜の”有効な存在”として表現できます。

（詳細：エラーハンドリング）

Q13. テスト戦略は？

A. 各存在（型）を単体で検証します。

事前条件＝#[Input]、事後条件＝publicプロパティ。ユースケースは#[Be]連鎖のスモークで十分に薄く保てます。

DIコストはありますが、副作用の局在化とバグ削減で総合的にプラスになります。ホットパスはReason実装で最適化可能です。

Q15. いつ「線形」「分岐」「ネスト」を選びますか？

A. 手順依存=線形／条件で結果が排他的=分岐／独立処理の合流=ネストです。

迷ったら最小限の線形から始めることをお勧めします。

（詳細：実装指針）

4) 既存資産との統合

Q16. 既存のMVCアプリに導入できますか？

A. はい、可能です。UseCase層をBeで置き換えて、Controllerからはbecoming(new …Input)を呼ぶことで実現できます。

徐々に内在/超越へ整理していくことができますので、段階的な移行が可能です。

Q17. DBや外部APIはどこで使いますか？

A. Reasonで。

保存や送信の手段はReasonに集約し、存在（状態）定義と分離します。

Q19. 静的解析やIDE補完は効きますか？

A. 型が”状態”なので効果的に効きます。

ユニオン型で分岐が明示化され、補完も安全です。

5) 運用・ログ・監査

Q20. ログはどう残りますか？

A. 従来のログと違い、実行全体が型づけされた意味的ログになります。

変容（from/to/理由/証跡）を構造化JSONで記録します。

（詳細：意味的ログ）

Q21. 監査対応はどうなりますか？

A. $been（自己証明）＋意味的ログで完全な監査証跡を提供可能です。

個人情報はReasonレイヤで最小権限を徹底します。

7) マイグレーション

Q24. 既存コードの移行手順は何ですか？（最小ステップ）

A. 以下の手順をお勧めします：

  1. 代表ユースケースを1つ選びます
  2. 入力を…Inputとして抽出します（内在のみ）
  3. 変換先を…（存在）として設計し、#[Be]を付与します
  4. 外部依存をReasonに集約します
  5. Controllerからbecoming(new …Input)を呼びます
  6. 意味変数へ検証を移管／例外を意味的に置換します
  7. 意味的ログを導入します

8) 将来機能

Q25. #[Accept]（拡張意思決定）はどのような機能ですか？

A. 構想段階の機能です。

確定できない判断を専門家やAIへ委譲し、確定性と不確実性を一つのフレームで扱う予定です。 決定を第一級市民として外部から制御可能にします。

（詳細：型駆動変容末尾の注記）

9) 例とスニペット

Q26. 典型フローの最小例はどのようなものですか？

A.

// 1) 入力（内在のみ）
#[Be(UserProfile::class)]
final readonly class UserInput {
    public function __construct(public string $name, public string $email) {}
}

// 2) 存在（変容の瞬間）
final readonly class UserProfile {
    public function __construct(
        #[Input] string $name,
        #[Input] string $email,
        #[Inject] NameFormatter $fmt,
        #[Inject] EmailValidator $v
    ) {
        $this->display = $fmt->format($name);
        $this->isValid = $v->validate($email);
    }
    public string $display;
    public bool $isValid;
}

// 3) 実行（自己組織化）
$profile = $becoming(new UserInput($name, $email));

// 結果: UserProfile オブジェクト
// $profile->display: "フォーマット済みの名前"
// $profile->isValid: true (有効なメールの場合)

10) 重要用語の詳細解説

存在指向 / Ontological（オントロジカル）

存在可能性と時間を一次の抽象として扱う設計観念です。従来の「何をするか」ではなく「何が存在できるか」を中心に据えた思考法で、プログラムの状態を時間的な存在として捉えます。

イマナンス / トランセンデンス（内在 / 超越）

イマナンス（内在）は、オブジェクトが本来持っている性質や情報を指します。トランセンデンス（超越）は、外部環境や依存関係から与えられる能力や情報を指します。Be Frameworkでは、この二つの組み合わせによって新しい存在が生まれます。

エンテレケイア（Entelecheia）

アリストテレス哲学に由来する概念で、潜在性が現実性へ移行する「変容の瞬間」を表します。Be Frameworkでは、コンストラクタで内在と超越が出会って新しい存在が完成する瞬間を指します。

存在理由層（Reason Layer）

ある存在状態が成立するために必要な根拠や道具一式をオブジェクトとして集約したものです。従来のDI（依存注入）を意味でまとめて、テスト容易性と保守性を高めます。

意味変数（Semantic Variables）

変数名そのものが意味と制約を表現する概念です。例えば$validEmailは「有効なEmail」でなければ存在できないという制約を名前で表現し、分散しがちな検証ロジックを型レベルで統合します。

意味的例外 / 意味的ログ

失敗や履歴を単純な文字列ではなく、意味を持った構造化されたデータとして保持する仕組みです。多言語対応や監査要件に対応し、システムの動作を意味レベルで追跡可能にします。

11) 関連章へのリンク