プロセス分析から蒸留・構造化・実装までのフレームワーク
現行業務（As-Is）の「手続き」をそのままシステム化（牛の道の舗装）せず、あるべき「意図」に昇華させてから実装に落とし込むための設計フレームワーク。
大きく3つのフェーズで構成される。
1. 蒸留（Distillation）: EventStormingでプロセスを分析し、手続きから「意図」と「境界」を抽出する
2. 構造化（Structuring）: CRCカードで「ヒト」も含めてモデリングする
3. 実装（Implementation）: 揺れ動く境界に強いDecider Patternを適用する
1. 蒸留（Distillation）
目的:
「どうやっているか（How/手続き）」を捨て、「何をしたいか（What/意図）」を抽出する。
ヒトとシステムの責務境界を定義する。
手順:
1. 業務領域の特定: スコープを定める:
概要レベルの分析に基づき、詳細に分析すべき複雑な業務領域を選定する
2. 詳細分析（As-Is）: 現行のイベントやリスクを詳細に洗い出す。（手続きレベル）
3. 手続きの宣言化:
「Excelを開く→コピーする」といった作業（Task）を、「予算を承認する」といったコマンドに変換する。
4. ポリシーの分類: 判断プロセスを以下の2つに分類し、境界を引く
決定論的（Deterministic）: 入力が同じなら結果も同じ システム（自動化）
確率的・直感的（Probabilistic）: 文脈や空気に依存する ヒト（意思決定）
2. 構造化（Structuring）
目的:
静的な構造の整合性を検証する。
開発者とドメインエキスパートのメンタルモデルを統一する。
重要なテクニック: Human as an Object
「ユーザー（ヒト）」もシステム外部の存在とせず、1枚のCRCカード（オブジェクト）として扱う。
システムとヒトを同列に並べ、メッセージのやり取りを設計する。
検証プロセス（ロールプレイング）:
シナリオに沿ってカードを動かす。
UI/APIの定義:
System -> Humanへの協力（Collaborator） = Read Model + Actor + Command
Human -> Systemへの依頼（Responsibility） = Event + Policy + Command
具体例:
3. 実装（Implementation）
ヒトとシステムの境界が頻繁に移動する（自動化が進む、または例外対応が増える）ことに適応するため、Decider Pattern（関数型Event Sourcing）を採用する。 アーキテクチャ上の優位性:
純粋関数（Pure Function）: (Command, State) -> List<Event>
副作用の分離: 判断ロジック（Decision）と、状態の保存や外部連携（Side Effects）を完全に切り離す。
メリット:
Pluggability: ロジックを「ヒト待ち（パススルー）」にするか「自動判定（アルゴリズム）」にするかの切り替えが、インフラ層に影響を与えない。
Auditability: 「誰が判断したか」がイベントとして記録されるため、自動/手動のハイブリッド運用でも追跡可能。
Testability: 状態遷移のテストにDBモックが不要。
具体例：与信審査プロセス
1. As-Is（手続き）
担当者が顧客DBを見て、年収が500万以上か確認し、過去の延滞履歴がないかExcelで照合し、問題なければハンコを押す。
2. To-Be（蒸留＆構造化）
CRCカードによる整理
Class: 審査担当者 (Human)
Resp: 例外的なリスクを判断する（直感）
Collab: 与信システム (Read)
Class: 与信システム (System)
Resp: 定量的なスコアリングを行う（決定論的ポリシー）
Resp: 審査結果を記録する
3. Implementation（Decider）
境界が移動（完全自動化へ移行）しても、Decide関数の中身を変えるだけで対応できる。
code:csharp
// Decider Function (Pure Logic)
List<Event> Decide(Command c, State s) {
return c match {
case RequestAudit cmd => {
// フェーズ1: ヒトに判断を委ねる場合
// フェーズ2: ポリシーを実装して自動化する場合
}
}
}
参照リンク・キーワード
Event Storming:
CRC Cards:
目的: オブジェクト指向設計で最も困難なのは、従来の手続き型プログラムで慣れ親しんだ「プログラム全体を制御する考え方（グローバルな制御）」から離れ、オブジェクトがそれぞれの責任を局所的に果たすという考え方に切り替えること
CRCカードとは:
CRCカードは、オブジェクトを次の三つの観点から捉えるためのカードです:
クラス名（Class）
責任（Responsibility）
協力者（Collaborators）
カードは実物のインデックスカードとして用いられ、下記のように書かれます:
上部に クラス名
左側に 責任のリスト（実行すべき機能）
右側に 協力するオブジェクト
CRCカードの使用法
マッピング: カードと並べ方と設計の理解
シナリオに基づく推敲: 構造化（分割と構成）
体験としての学習: CRCカードとしてシナリオをロールプレイ
Decider Pattern: