iGaming 코어의 DDD
iGaming 플랫폼은 금융, 엔터테인먼트 및 규정 준수의 교차점에있는 복잡한 도메인 시스템입니다. DDD는 복잡성을 유지하는 데 도움이됩니다. 경계 상황을 강조하고, 유비쿼터스 언어를 캡처하고, 집계로 불변량을 보호하고, 반부패 계층을 통한 통합을 단순화하고, 도메인 이벤트를 통해 시스템 동작을 투명하게 만듭니다.
1) 도메인 맵 및 경계 상황 (전략적 디자인)
권장 분해:- 플레이어/KYC 컨텍스트-등록, 확인, 책임있는 게임 제한, KYC/AML 상태.
- 지갑/원장 상황-잔액, 예약, 거래, 다중 요금, 환율.
- 베팅 컨텍스트-베팅/티켓, 페어/결과, 견적, 결제, 취소.
- 카지노/게임 라운드 컨텍스트-세션, 라운드, 백, RTP 컨트롤, 베팅 제한.
- 보너스/프로모션 컨텍스트-보너스 규칙, 베팅, 보너스 자금 획득, 남용 방지.
- 위험/사기 상황-점수, 행동 신호, 잠금/시간 초과 트리거.
- 결제 상황-예금/인출, 결제 게이트웨이 상태, 요금 환급 이벤트.
- 규정 준수/보고 상황-규제 기관, 제재 목록, 감사에보고합니다.
- 컨텐츠/제공자 통합 컨텍스트-게임 제공 업체, 카탈로그, 기술과의 통합. 상태.
- 분석/읽기 모델-제품 판독을위한 프로젝션 및 쇼케이스.
2) 유비쿼터스 언어: 용어의 핵심
플레이어, 세션, GameRound, 베팅/티켓,
원장 입장, 홀드/리저브, 합의,
보너스 크레딧/보너스 밸런스, Wagering Requirement (
KYC Tier, Limit (예금/세션/손실), 자체 제외,
공급자 게임, RTP 창, 위험 깃발, 준수 사례.
이 이름은 코드, 데이터베이스, 문서, 테스트 및 인터페이스에서 동일하게 사용됩니
3) 집계 및 불변량 (전술 설계)
3. 지갑 1 개 (집계: '지갑')
불변량:- 균형은 부정적인 영역으로 들어 가지 않습니다.
- 총 잔액을 저장하십시오.
- 배선은 원자적이고 demmpotent입니다 ('operation _ id').
- '지갑. 예약 (양, 이유, op _ id) '→' WalletReserved '
- '지갑. Commit (op _ id) '→' WalletCommitted '
- '지갑. 롤백 (op _ id) '→' WalletRolledBack '
테두리: 월렛은 베팅/보너스에 대해 모른다. 게시 및 예약 거래를 제공합니다.
3. 2 베팅/티켓 (집계: '베팅')
불변량:- 요율은 활성 견적 창에서만 허용 될 수 있습니다. 플레이어/세션 제한을 합산하십시오.
- '정착' 후 상태는 '완료' 됩니다. 재 계산은 명확한 감사를 통해 보상 작업 (void/recalc) 을 통해서만 허용됩니다.
- '내기. 장소 (플레이어 _ id, 금액, 가격, op _ id) '→' BetPlaced '(тре 예약)
- '내기. 정착 (결과, 지불) '→' BetSettled '(월렛 필요) 커밋/릴리스)
- '내기. 공허 (이유) '→' BetVoide '
테두리: 내기는 월렛으로 "올라가지" 않습니다. 도메인 명령/오케스트레이션을 통해 호출됩니다.
3. 3 게임 라운드 (집계: '라운드')
불변량:- 각 스핀/라운드에는 고유 한 'round _ id' 와 관련 베팅/윈 금액이 있습니다.
- RTP 창은 지정된 임계 값을 초과하지 않습니다 (공급자 수준 + 로컬 규칙).
- '둥근. ',' 라운드를 시작했습니다. ',' 라운드. 결과 ',' 라운드. 닫혔습니다. '
3. 4 보너스 (집계: '보너스 그랜트')
불변량:- 베이거는 유효한 회전율에서만 감소하며 보너스 상환액은 직불 결제되지 않습니다.
- 우선 순위 규칙에 따르지 않고 보너스와 실제 자금을 동시에 상각 할 수 없습니다.
- 'BonusGranted', 'BonusWagery', 'BonusManifred', 'BonusConverted'.
4) 오케스트레이션, 사가 및 일관성
Synchronous (CP): 베팅 및 자금 준비금 수락-한 가지 방법: 'Bet. '→' 지갑을 놓습니다. 예약 '(마감일이있는 도메인 팀/오케 스트레이터를 통해).
비동기 (EC): 이벤트 + 아웃 박스를 통한 속도 계산, 보너스 발생, 분석.
TCC 변형: 화폐 효과에 대한 'TryReserve' (보류), '확인' (커밋), '취소' (롤백).
이데올로기: 모든 명령에는 'operation _ id', 소비자- '받은 편지함' 이 있습니다.
5) 반부패 계층 (ACL) 및 통합
공급자 ACL: 공급자 이벤트 'SpinResult', 'BonusWin' to internal 'Round 번역. 결과 ',' BonusWagery '. 스키마 및 버전은 ACL 내에 있습니다.
PSP ACL: 결제 상태의 정규화, 'psp _ tx _ id' 에 의한 demotency, 'LedgerEntry' 로 이전.
준수 ACL: 외부 상황에서 제재 목록/RAP와의 통합; 정규화 된 '시나리오 업데이트' 만 도메인 안에 들어갑니다.
규칙: 외부 사전/형식은 커널에 "누설" 되지 않습니다.
6) 투영 및 읽기 모델
플레이어 프로필 읽기 모델: KYC 상태, 한계, 적극적인 보너스, 새로운 거래.
밸런스 읽기 모델: UI/마케팅에 대한 빠른 읽기; 소스- '지갑' 이벤트.
내기 기록 읽기 모델: 날짜/게임별 페이지 작성; 출처는 'BetPlaced/Settled' 입니다.
규정 준수 보고서-임차인/지역별 재료 화보기.
모든 프로젝션은 버전 및 'as _ of/freshness' 를 갖춘 demotent upserts입니다.
7) 다중 테넌트 및 다중 지역
모든 주요 엔티티에는 '테넌트 _ id' 및 (필요한 경우) '영역' 이 있습니다.
데이터 경계: 플레이어, 지갑, 베팅- "홈" 영역; 교차 지역 집계/보고서 만.
공정성/할당량: 팀/초에 대한 제한 및 임차인에 대한 재 드라이브.
거주/준수: 개인 데이터 및 거래는 해당 지역을 떠나지 않습니다.
8) 컨텍스트 별 일관성 선택 (PACELC)
월렛/원장-강력한/CP: 선형 트랜잭션, 정족수.
내기 수락-UI에 대한 동기 확인 (CP) + 빠른 읽기 모델.
결정/보너스/분석-결정 론적 합병/보상이있는 EC.
KYC/준수-상태에 대해서는 EC 일 수 있지만 "차단" 규칙은 동기식으로 적용됩니다.
9) 도메인 이벤트: 계약 및 버전
최소 필드 세트:json
{
"event_id": "uuid",
"event_type": "BetPlaced",
"occurred_at": "timestamp",
"tenant_id": "T123",
"aggregate_id": "BET-...-UUID",
"version": 7,
"payload": { "...domain fields..." },
"schema_version": "v3"
}- 백/포워드 컴파트 체계; '스키마 _ 버전' 을 통한 진화.
- 도메인 변경과의 거래에서 'outbox'; 백오프와 함께 버치로 출판.
10) "보너스가있는 베팅" 흐름의 예 (단어 순서)
1. '내기. 장소 '(팀) → 플레이어 제한 및 →' 월렛 보너스 규칙 확인. 예약 (실제 + 보너스 _ equiv, op _ id) '
2. 'BetPlaced' → 모델 업데이트 'Open Wagers' 읽기
3. 공급자는 결과 → → 'Round ACL을 게시합니다. 결과 '
4. 오케스트라 터는 다음과 같이 계산합니다. 정착 (결과, 지불) '→' 지갑. Commit (op _ id) '및 이기면' BonusWagery '→ 보너스를 실제 보너스로 변환 할 수 있습니다.
5. 'BetSettled' → 역사 및 대차 대조표 예측, 보고.
11) 불변량 및 테스트 정책
주요 불변량:- 지갑의 모든 'LedgerEntry' 의 합은 잔액과 같습니다. 음의 잔차가 없습니다.
- 활성 자체 제외/동결 된 KYC 상태로 베팅을 수락 할 수 없습니다.
- 베팅은 "마이너스" 로 줄어들고 스윙 할 수 없습니다.
- 결제는 이미 최종 요율의 상태를 변경하지 않으며 'Void/Recalc' + 오프셋 트랜잭션을 통해서만 변경됩니다.
- 지갑 불변 및 베팅에 대한 부동산 기반 테스트.
- 혼돈의 경쟁: 공급자 지연, PSP 실패, 아웃 박스/DLQ 재구동.
- 스키마 제어: 이벤트 마이그레이션, 백필 프로젝션.
12) 원격 측정 및 감사
메트릭: PlaceBet/Reserve/Commit의 p95/p99, 한도/ACC, DLQ 비율에 의한 고장 비율, 재구성 성공, 지연 예측.
추적: "komanda → agregat → outbox → konsyumer → proyektsiya", 태그 'tenant _ id', 'operation _ id', 'saga _ id'.
감사: 규제 요구 사항과 비슷한 변하지 않는 도메인 활동 로그.
13) 저장 체계 (단순화)
지갑:
wallet(id, tenant_id, currency, balance, reserved, version)
ledger(id, wallet_id, amount, type, operation_id, occurred_at)
holds(id, wallet_id, amount, operation_id, expires_at, status)
bet(id, tenant_id, player_id, amount, price, status, placed_at, settled_at, operation_id)
bonus_grant(id, tenant_id, player_id, amount, wager_left, status, expires_at)골재 버전 ('버전') 은 경쟁 기록 중 손실 된 업데이트로부터 보호합니다.
14) 예 명령 API (의사)
http
POST /bets. place
{
"tenant_id":"T1",
"player_id":"P42",
"amount":"10. 00",
"price":"2. 1",
"operation_id":"op-uuid",
"context":{"game_id":"g777","channel":"web"}
}
→ 202 Accepted + BetPlaced
POST /wallets. reserve
{ "wallet_id":"W1", "amount":"10. 00", "operation_id":"op-uuid", "reason":"bet" }
→ 200 { "reserved_balance":"..." }모든 명령은 demempotency에 대해 'operation _ id' 를 사용하고 응답은 'as _ of '/' 버전을 사용합니다.
15) 안전 및 준수
RLS/ACL: 모든 요청-' tenant _ id '와 관련하여 역할별로 액세스하십시오.
PII 최소화: 개인 데이터에서 도메인 이벤트 분리; DLQ/로그에서 마스킹.
규제 보고서: 시간 창에서 해시 서명이 변경되지 않은 투영.
16) 전형적인 오류
상황 간의 강력한 연결성 (Wallet은 Bet/Bonus를 직접 알고 있음).
사가/아웃 박스 → 균형과 상태의 불일치없이 다른 상황에 이중 쓰기.
명령 부족 및 소비자 demempotency → 중복 트랜잭션/계산.
공급자의 흐름은 도메인 모델로 계약됩니다 (마이그레이션하기가 더 어렵습니다).
하나의 "거대한" 집계 (플레이어는 모두 포함) 잠금 → 낮은 처리량입니다.
명백한 불변량은 없습니다. 확인하고 모니터링 할 수 없습니다.
17) 빠른 레시피
시작: 유비쿼터스 언어 및 컨텍스트 경계를 수정합니다. 문서 불변.
돈: 지갑/원장-CP, 쿼럼 항목, 외부 효과를위한 TCC.
베팅: 이벤트 및 아웃 박스를 통한 동기 수신 + 비동기 계산; demempotency는 어디에나 있습니다.
보너스: 명확한 상각 우선 순위와 베이거가있는 별도의 장치.
통합: 항상 ACL + 체계/버전을 통해; 코어에 "원시" 페이로드가 없습니다.
읽기: 제품 요구에 대한 투영/표시; SLA 신선도 + 'as _ of'.
운영: 불변량의 지표, DLQ/redrave 플레이 북, 쇼케이스 재건.
18) 사전 판매 점검표
- 경계 상황 및 계약 (명령/이벤트) 이 정의됩니다.
- 집계에는 명시 적 불변, 버전 지정 및 dem 등원 명령이 있습니다.
- 통화 거래-TCC/엄격한 거래를 통한; 감사가 활성화되었습니다.
- 통합-스키마 버전 지정 및 진화 테스트가있는 ACL을 통한 통합.
- 구현 된 아웃 박스/받은 편지함, DLQ 및 안전한 재 추첨.
- 투영은 SLA 신선도를 구현하며 지연/정체 지표가 있습니다.
- 다중 세입자 할당량/제한 및 데이터 거주가 충족됩니다.
- 관찰 가능성: "komanda → sobytiye → proyektsiya" 추적, 불변량에 의한 경고.
- 문서: 도메인 언어, 컨텍스트 다이어그램, 사건 플레이 북.
결론
iGaming 코어의 DDD는 명확한 맥락 경계, 불변량과의 집계, 진실의 원천으로서의 사건, 외부 통합을위한 ACL 및 정보에 입각 한 일관성 선택과 같은 복잡성의 분리 분야입니다. 이 접근 방식은 트래픽, 지역 및 제품 라인의 빠른 성장에도 불구하고 플랫폼을 확장 가능하고 신뢰할 수 있으며 규정을 준수하며 기능 개발 속도를 높이고 운영 위험을 줄입니다.