VSA Boundary Modeler

このスキルは、UI がある機能における Boundary モデリングの自動想起を目的とする。

重要: AI の学習データには「Boundary をモデリングする」という発想がほとんど含まれていない。 このスキルにより、UI 機能の設計・実装時に Boundary パターンを自動的に想起させる。

---

適用場面

• UI を持つ機能の設計・実装
• フォーム、一覧画面、詳細画面の作成
• 操作可否判定（ボタン活性/非活性）
• ユーザーの意図（Intent）に基づく操作

---

Boundary パターンの核心

業務ロジックは Entity が持つ。BoundaryService は委譲のみ。

UI → BoundaryService → Entity.CanXxx()
       ↓                    ↓
    データ取得のみ      業務ルール判定

---

開発フロー（推奨順序）

Step 1: Intent 定義

ユーザーができる操作（意図）を列挙する。

// 例: 注文画面の Intent
public enum OrderIntent
{
    Pay,      // 支払い
    Cancel,   // キャンセル
    View      // 詳細表示
}

Step 2: Entity.CanXxx() 設計

各 Intent に対応する CanXxx() メソッドを Entity に実装する。

public class Order : AggregateRoot<OrderId>
{
    public BoundaryDecision CanPay()
    {
        return Status switch
        {
            OrderStatus.Pending => BoundaryDecision.Allow(),
            OrderStatus.Paid => BoundaryDecision.Deny("既に支払い済みです"),
            OrderStatus.Cancelled => BoundaryDecision.Deny("キャンセル済みの注文です"),
            _ => BoundaryDecision.Deny("この状態では支払いできません")
        };
    }

    public BoundaryDecision CanCancel()
    {
        if (Status == OrderStatus.Paid)
            return BoundaryDecision.Deny("支払い済みの注文はキャンセルできません");

        if (Status == OrderStatus.Cancelled)
            return BoundaryDecision.Deny("既にキャンセル済みです");

        return BoundaryDecision.Allow();
    }
}

Step 3: BoundaryService 実装

データ取得と Entity への委譲のみを行う。

public class OrderBoundaryService : IOrderBoundary
{
    private readonly IOrderRepository _repository;

    public async Task<BoundaryDecision> ValidatePayAsync(OrderId id, CancellationToken ct)
    {
        var order = await _repository.GetByIdAsync(id, ct);

        // 存在チェックのみ許可
        if (order == null)
            return BoundaryDecision.Deny("注文が見つかりません");

        // ★ 業務ロジックは Entity に委譲
        return order.CanPay();
    }
}

---

BoundaryDecision クラス

public sealed class BoundaryDecision
{
    public bool IsAllowed { get; }
    public string? Reason { get; }

    private BoundaryDecision(bool isAllowed, string? reason = null)
    {
        IsAllowed = isAllowed;
        Reason = reason;
    }

    public static BoundaryDecision Allow() => new(true);
    public static BoundaryDecision Deny(string reason) => new(false, reason);
}

---

禁止事項

BoundaryService に業務ロジックを書かない

// ❌ 禁止: BoundaryService に業務ロジック
public async Task<BoundaryDecision> ValidatePayAsync(OrderId id, CancellationToken ct)
{
    var order = await _repository.GetByIdAsync(id, ct);

    // ↓ これは業務ロジック！Entity.CanPay() に移動すべき
    if (order.Status == OrderStatus.Paid)
        return BoundaryDecision.Deny("既に支払い済みです");

    return BoundaryDecision.Allow();
}

---

優先権のある操作（FR-021 対策）

Ready 状態の予約者がいる場合など、優先権を考慮する必要がある場合：

// Entity.CanBorrow に優先権エンティティを渡す
public BoundaryDecision CanBorrow(MemberId memberId, MemberId? readyReserverId)
{
    if (Status != BookCopyStatus.Available && Status != BookCopyStatus.Reserved)
        return BoundaryDecision.Deny("このコピーは貸出可能状態ではありません");

    // ★ Ready状態の予約者がいる場合、その人以外は Deny
    if (readyReserverId.HasValue && readyReserverId.Value != memberId)
    {
        return BoundaryDecision.Deny(
            "予約者に優先権があります。予約者の貸出処理をお待ちください。");
    }

    return BoundaryDecision.Allow();
}

---

チェックリスト

UI がある機能を設計・実装する際は、以下を確認：

□ Intent（ユーザーの意図）を列挙したか？
□ 各 Intent に対応する Entity.CanXxx() を設計したか？
□ CanXxx() は BoundaryDecision を返すか？
□ BoundaryService に業務ロジック（if 文）がないか？
□ 優先権のある操作は CanXxx() に優先権エンティティを渡しているか？

---

計画が不完全とみなされる条件

条件	判定
UI があるのに Boundary セクションがない	❌ 不完全
Intent が定義されていない	❌ 不完全
Entity.CanXxx() の設計がない	❌ 不完全
「後から Boundary を追加する」という計画	❌ 不完全

---

参照

詳細は catalog/patterns/boundary-pattern.yaml を参照。