> ## Documentation Index
> Fetch the complete documentation index at: https://docs.uselim.com/llms.txt
> Use this file to discover all available pages before exploring further.
# イベント駆動設計
> limのイベント駆動アーキテクチャの仕組みと設計思想。
# イベント駆動設計
limはイベント駆動アーキテクチャを採用しています。すべての会計処理は、外部から流入するイベントをトリガーとして実行されます。
## アーキテクチャ概要
```
┌──────────────────────┐
│ Event Sources │
│ Bank API │ Webhook │
│ MCP Tool │ Manual │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ Event Queue │
│ PG LISTEN/NOTIFY │
│ + event table │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ Judgment Engine │
│ Rule → History → AI │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ Journal Entries │
│ Audit-logged ledger │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ Real-time Queries │
│ TB │ PL │ BS │ CF │
└──────────────────────┘
```
## イベントの流れ
### 1. イベントの取込
外部システムからイベントを受信します:
```json theme={null}
{
"type": "bank_transaction",
"source": "mizuho_api",
"data": {
"date": "2026-03-15",
"amount": -11000,
"description": "ｶ）ｴｰﾀﾞﾌﾞﾘﾕｰｴｽ",
"balance": 2389000
}
}
```
### 2. イベントの正規化
取込まれたイベントは共通フォーマットに正規化されます:
```json theme={null}
{
"id": "evt_01J7...",
"type": "expense",
"vendor": "AWS",
"amount": 11000,
"currency": "JPY",
"date": "2026-03-15",
"payment_method": "bank_transfer"
}
```
### 3. Judgment Engineによる処理
正規化されたイベントがJudgment Engineに渡され、仕訳が生成されます。
### 4. 仕訳の記帳
生成された仕訳がレジャーに記帳され、すべての財務データがリアルタイムに更新されます。
## PG LISTEN/NOTIFY
limはPostgreSQLの `LISTEN/NOTIFY` をイベントバスとして使用します。シンプルさと信頼性を両立する設計です。
* **NOTIFY**: イベントがDBに挿入されると通知を発行
* **LISTEN**: ワーカーが通知を受信して処理を開始
* **Polling fallback**: 通知を取りこぼした場合のポーリング
外部のメッセージブローカー（Kafka、RabbitMQ等）は使いません。PostgreSQLだけで完結するため、インフラがシンプルです。
## イベントグラフ
イベント間の因果関係をグラフとして記録します:
```
銀行取引(evt_01) → 仕訳作成(evt_02) → 残高更新(evt_03)
→ ルール学習(evt_04)
```
これにより、任意の仕訳について「なぜこの仕訳が作られたのか」を完全に追跡できます。
## 冪等性
同じイベントが複数回処理されても結果は変わりません。イベントIDによる重複検知が組み込まれています。
```
process(event) → journal_entry (1回目: 作成)
process(event) → no-op (2回目: スキップ)
```
## 次のステップ
関数としての会計の設計思想。
AI AgentをイベントソースとしてGreen接続。