イベント駆動設計
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. イベントの取込
外部システムからイベントを受信します:
{
"type": "bank_transaction",
"source": "mizuho_api",
"data": {
"date": "2026-03-15",
"amount": -11000,
"description": "ｶ）ｴｰﾀﾞﾌﾞﾘﾕｰｴｽ",
"balance": 2389000
}
}
2. イベントの正規化
取込まれたイベントは共通フォーマットに正規化されます:
{
"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回目: スキップ)
次のステップ
