はじめに
FinTech プラットフォームは、単純なモノリシック アプリケーションではありません。明確に分離する必要がある多くの異なるドメインを含む複雑なシステムです。この記事では、マイクロサービス と ドメイン駆動設計 (DDD) を使用して全体的なアーキテクチャを設計します。
1. 高レベルのアーキテクチャ
1.1 システム概要
┌─────────────────────────────────────────────────────────┐
│ CLIENT LAYER │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │Mobile App│ │ Web App │ │Merchant │ │Partner │ │
│ │ │ │ │ │Dashboard │ │ API │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └───┬────┘ │
└───────┼──────────────┼─────────────┼────────────┼───────┘
│ │ │ │
┌───────▼──────────────▼─────────────▼────────────▼───────┐
│ API GATEWAY LAYER │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ API Gateway (Kong/Envoy) │ │
│ │ ├── Rate Limiting ├── Authentication │ │
│ │ ├── Request Routing ├── SSL Termination │ │
│ │ └── API Versioning └── Request/Response Transform │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────┬───────────────────────────────┘
│
┌─────────────────────────▼───────────────────────────────┐
│ SERVICE MESH │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │
│ │ Payment │ │ Wallet │ │ Ledger │ │ Risk │ │
│ │ Service │ │ Service │ │ Service │ │ Service │ │
│ └──────────┘ └──────────┘ └──────────┘ └────────────┘ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │
│ │ Identity │ │ Merchant │ │Reporting │ │Notification│ │
│ │ Service │ │ Service │ │ Service │ │ Service │ │
│ └──────────┘ └──────────┘ └──────────┘ └────────────┘ │
└─────────────────────────┬───────────────────────────────┘
│
┌─────────────────────────▼───────────────────────────────┐
│ DATA LAYER │
│ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────────┐│
│ │PostgreSQL│ │Redis │ │Kafka │ │ S3 │ │Elasticsearch││
│ └───────┘ └───────┘ └───────┘ └───────┘ └───────────┘│
└─────────────────────────────────────────────────────────┘
1.2 設計原則
- ドメインファースト: 技術層ではなくドメインごとにサービスを分割します。
- サービスごとのデータベース: 各サービスは独自のデータを所有します。
- イベント駆動型通信: クロスドメインの非同期通信
- API ファーストの設計: OpenAPI によるコントラクトファーストのアプローチ
- 多層防御: あらゆる層でのセキュリティ
2. FinTech 向けのドメイン駆動設計
2.1 戦略的設計 — 境界のあるコンテキスト
┌─────────────────────────────────────────────────────────────┐
│ FINTECH PLATFORM │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ IDENTITY │ │ PAYMENT │ │ WALLET │ │
│ │ Context │ │ Context │ │ Context │ │
│ │ │ │ │ │ │ │
│ │ • User │ │ • Payment │ │ • Account │ │
│ │ • KYC │ │ • Refund │ │ • Balance │ │
│ │ • Auth │ │ • PSP │ │ • Transaction │ │
│ │ • Session │ │ • Checkout │ │ • Transfer │ │
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ LEDGER │ │ RISK │ │ MERCHANT │ │
│ │ Context │ │ Context │ │ Context │ │
│ │ │ │ │ │ │ │
│ │ • Journal │ │ • Fraud │ │ • Merchant │ │
│ │ • Account │ │ • AML │ │ • Settlement │ │
│ │ • Posting │ │ • KYC │ │ • Fee │ │
│ │ • Balance │ │ • Scoring │ │ • Contract │ │
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ LENDING │ │ REPORTING │ │ NOTIFICATION │ │
│ │ Context │ │ Context │ │ Context │ │
│ │ │ │ │ │ │ │
│ │ • Loan │ │ • Report │ │ • Template │ │
│ │ • Credit │ │ • Dashboard │ │ • Channel │ │
│ │ • Schedule │ │ • Export │ │ • Preference │ │
│ │ • Offer │ │ • Audit │ │ • History │ │
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
2.2 コンテキストマッピング
Identity ──[U/D]──► Payment (Identity upstream, Payment downstream)
Payment ──[Pub]──► Ledger (Payment publishes events, Ledger subscribes)
Payment ──[Pub]──► Risk (Payment publishes for fraud check)
Payment ──[ACL]──► PSP (Anti-corruption layer for external PSPs)
Wallet ──[Pub]──► Ledger (Wallet changes reflected in Ledger)
Merchant ──[Pub]──► Reporting (Merchant events feed Reporting)
Risk ──[U/D]──► Payment (Risk provides scoring to Payment)
使用パターン:
- 公開言語: イベントは同じスキーマを使用します (Avro/Protobuf)
- 破損防止レイヤー (ACL): 外部 PSP API をラップする
- 上流/下流 (U/D): 明確な依存関係の方向
- 共有カーネル: 一般的なタイプ (お金、通貨、住所)
2.3 共有カーネル — 共通値オブジェクト
// Shared across all bounded contexts
public record Money(BigDecimal amount, Currency currency) {
public Money {
if (amount.scale() > currency.getDefaultFractionDigits()) {
throw new IllegalArgumentException("Invalid precision");
}
}
public Money add(Money other) {
requireSameCurrency(other);
return new Money(amount.add(other.amount), currency);
}
}
public record TransactionId(String value) {
// UUID v7 for time-ordered IDs
public static TransactionId generate() {
return new TransactionId(UUIDv7.generate().toString());
}
}
3. マイクロサービス アーキテクチャ
3.1 サービストポロジ
┌──────────────┐
│ API Gateway │
└──────┬───────┘
│
┌────────────────┼────────────────┐
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ Payment │ │ Wallet │ │ Identity │
│ Service │ │ Service │ │ Service │
│ │ │ │ │ │
│ PostgreSQL │ │ PostgreSQL │ │ PostgreSQL │
│ Redis │ │ Redis │ │ Redis │
└──────┬──────┘ └──────┬──────┘ └─────────────┘
│ │
└────────┬───────┘
│
┌──────▼──────┐
│ Kafka │ Event Bus
└──────┬──────┘
│
┌─────────────┼─────────────┐
│ │ │
┌────▼────┐ ┌─────▼─────┐ ┌────▼────┐
│ Ledger │ │ Risk │ │Reporting│
│ Service │ │ Service │ │ Service │
│ │ │ │ │ │
│PostgreSQL│ │PostgreSQL │ │ClickHouse│
└─────────┘ │ Redis │ └─────────┘
│ ML Model │
└───────────┘
3.2 通信パターン
| パターン | 使用例 | 例 |
|---|---|---|
| 同期 (REST/gRPC) | リアルタイムクエリ | 残高の確認、支払い状況の取得 |
| 非同期 (イベント) | 状態の変化 | 支払い完了 → 台帳更新 |
| コマンド | アクションリクエスト | 支払いの処理、返金の作成 |
| クエリ | 読み取り専用 | 取引履歴を取得する |
3.3 サービスごとのデータベース
Payment Service ──► payment_db (PostgreSQL)
├── payments
├── payment_methods
├── payment_attempts
└── refunds
Wallet Service ──► wallet_db (PostgreSQL)
├── accounts
├── balances
├── transactions
└── holds
Ledger Service ──► ledger_db (PostgreSQL)
├── journal_entries
├── postings
├── accounts
└── balances
Risk Service ──► risk_db (PostgreSQL + Redis)
├── fraud_rules
├── risk_scores
├── blacklists
└── ml_features (Redis)
4. イベント駆動型アーキテクチャ
4.1 ドメインイベント
Payment Domain Events:
├── PaymentInitiated
├── PaymentAuthorized
├── PaymentCaptured
├── PaymentFailed
├── PaymentRefunded
└── PaymentSettled
Wallet Domain Events:
├── AccountCreated
├── BalanceCredited
├── BalanceDebited
├── TransferInitiated
├── TransferCompleted
└── HoldPlaced
Risk Domain Events:
├── FraudCheckRequested
├── FraudCheckCompleted
├── RiskScoreCalculated
├── TransactionBlocked
└── AlertRaised
4.2 イベントスキーマ (Avro)
{
"type": "record",
"name": "PaymentCompletedEvent",
"namespace": "com.fintech.payment.events",
"fields": [
{"name": "eventId", "type": "string"},
{"name": "eventType", "type": "string"},
{"name": "timestamp", "type": "long"},
{"name": "paymentId", "type": "string"},
{"name": "amount", "type": {"type": "record", "name": "Money", "fields": [
{"name": "value", "type": "string"},
{"name": "currency", "type": "string"}
]}},
{"name": "merchantId", "type": "string"},
{"name": "customerId", "type": "string"},
{"name": "paymentMethod", "type": "string"},
{"name": "status", "type": "string"}
]
}
4.3 イベント フロー — 支払い処理
Customer ─── Initiate Payment ───► Payment Service
│
├──► Risk Service (Fraud Check)
│ │
│ ◄──┤ (Approved/Rejected)
│
├──► PSP (Authorize)
│ │
│ ◄──┤ (Auth Response)
│
├──► Event: PaymentAuthorized
│ │
│ ├──► Wallet Service (Debit)
│ ├──► Ledger Service (Record)
│ ├──► Notification Service
│ └──► Reporting Service
│
└──► Response to Customer
5. API ゲートウェイの設計
5.1 ゲートウェイの責任
API Gateway Configuration:
authentication:
- JWT validation
- API key verification
- mTLS for service-to-service
rate_limiting:
default: 100 req/min
premium: 1000 req/min
merchant_api: 5000 req/min
routing:
/api/v1/payments/* → payment-service
/api/v1/wallets/* → wallet-service
/api/v1/merchants/* → merchant-service
/api/v1/reports/* → reporting-service
security:
- CORS policies
- Request validation
- IP whitelisting (for merchant APIs)
- PCI-DSS compliant headers
5.2 API のバージョン管理戦略
/api/v1/payments ← Current stable
/api/v2/payments ← Next version (beta)
Header-based: Accept: application/vnd.fintech.v1+json
6. 横断的な懸念事項
6.1 可観測性スタック
┌──────────────────────────────────────┐
│ OBSERVABILITY STACK │
├──────────────────────────────────────┤
│ Metrics: Prometheus + Grafana │
│ Logging: ELK Stack / Loki │
│ Tracing: OpenTelemetry + Jaeger │
│ Alerting: PagerDuty / OpsGenie │
└──────────────────────────────────────┘
6.2 セキュリティ層
Defense in Depth:
├── Network: VPC, Security Groups, WAF
├── Transport: TLS 1.3, mTLS
├── Application: JWT, OAuth2, RBAC
├── Data: Encryption at rest (AES-256)
├── Payment: Tokenization, HSM
└── Audit: Immutable audit logs
概要
FinTech プラットフォーム アーキテクチャには次のものが必要です。
- DDD により、複雑なドメインを明確に境界付けられたコンテキストに分割します
- 分離のためのサービスごとのデータベースを備えた マイクロサービス
- イベント駆動による疎結合と最終的な整合性
- API ゲートウェイ によるセキュリティ、ルーティング、レート制限
- 多層防御であらゆる層のセキュリティを実現
次の記事: 規制コンプライアンス (PCI-DSS、PSD2、およびベトナム国立銀行の規制) と、コンプライアンス要件を満たすシステムの設計方法について詳しく説明します。