경계 상황과 도메인 경계
BC (Bounded Contex) 는 단일 유비쿼터스 언어, 일관된 모델 및 불변량이 작동하는 명확한 경계입니다. 국경 내부에서 용어는 모호하지 않으며 ("베팅", "클라이언트", "제한") 상황 외부에서는 계약 (이벤트/팀) 과 통신하며 다른 사람들의 의미 론적 "꼬리 안으로 들어 가지 않습니다. "똑똑하게 선택한 경계는 연결성을 줄이고 스케일링을 단순화하며 제품 진화를 가속화
1) 왜 우리는 국경이 필요한가
인지 부하 감소. 이 팀은 "한 번에 전체 비즈니스" 가 아닌 하나의 모델과 하나의 언어로 작업합니다.
불변량의 격리. 중요한 규칙 (밸런스 이하 0, 로그인 고유성) 은 한 곳에 있으며 집계로 보호됩니다.
관리 변경. BC 주 내에서 계획/규칙의 진화는 이웃을 깨뜨리지 않습니다. 명백한 계약이 있습니다.
성능과 신뢰성. BC 주 내에서 적절한 일관성 모델과 스토리지를 선택할 수 있습니다. 외부-비동기 투영.
2) 경계 상황을 식별하는 방법
빠른 방법 (워크샵 2-4 시간):1. 이벤트 폭풍: 도메인 이벤트를 "무슨 일이 있었는지" 기록한 다음 "무엇을 요청하는지" 명령 한 다음 "규칙을 보장하는 사람" 을 집계합니다.
2. 언어 클러스터: 단어와 규칙이 일관되게 일치하는 경우-잠재적 BC. "클라이언트" 라는 단어가 다른 의미 (지불 자 대 플레이어) 인 경우 분명히 다른 상황이 있습니다.
3. 불변량과 소유권: 무엇을 위반할 수 없으며 누가 책임이 있습니까? 그것을 보장 할 수있는 BC 내부의 불변의 →.
4. 가치 흐름: 종종 함께 변하는 그룹 단계 - 이들은 하나의 BC 후보입니다.
5. 조직 구조: 한 부분이 별도의 KPI를 가진 별도의 팀에 의해 만들어지는 경우-이것은 아마도 별도의 BC 일 것입니다 (그러나 그 반대는 아닙니다. 조직 구조가 모델을 맹목적으로 지시해서는 안됩니다).
경계 신호:- 용어에 대한 분쟁 ("베팅", "티켓", "라운드" -다른 의미).
- 서비스를 통해 가장 인기있는 "흐름".
- 다른 SLO와 변화 속도.
- 원자성을 위해 모듈 간의 "이중 쓰기".
3) 전형적인 상황 (도메인 예)
신원/KYC-등록, 검증 수준, 제한 상태.
지갑/원장-잔액, 거래, 준비금, 통화.
베팅/주문-수신, 견적, 계산.
게임/라운드-라운드 라이프 사이클, 결과.
보너스/프로모션-발생, 베이거, 전환.
결제-예금/인출, 결제 게이트웨이 상태.
준수/보고-보고서, 감사, 규제 쇼케이스.
카탈로그/공급자 통합 - 게임, 버전, 공급자의 상태.
분석/읽기 모델-예측 및 구체화 된 견해.
4) 상황지도: BC가 상호 작용하는 방법
컨텍스트 맵은 관계 유형을 캡처합니다
고객 공급 업체. 하나의 BC (공급 업체) 는 이벤트/데이터를 제공하고 다른 하나 (고객) 는 모델을 조정합니다.
순응 자. 고객은 공급 업체 언어 및 모델을 그대로 허용합니다 (예: 규제 원장).
파트너십. 두 개의 BC가 동기식으로 언어와 계약을 발전시킵니다 (종종 하나의 명령/로드맵).
공유 커널. 공동으로 작성된 최소 하위 언어/라이브러리; 조심스럽게 사용하십시오.
부패 방지 계층 (ACL). 다른 사람들의 모델을 자신의 언어로 변환하는 보호 레이어.
오픈 호스트 서비스/게시 된 언어. 공개 프로토콜/체계, 다양성 및 문서화.
연습: 기본적으로 ACL 및 비동기 이벤트를 사용하십시오 공급자가 표준 공유 커널을 지시하는 경우에만 적합합니다.
5) 경계 = 언어 + 모델 + 불변 + 저장
기원전 내부에서 다음을 정의하십시오
유비쿼터스 언어. 예제가있는 용어 사전.
집계 및 불변. 누가 규칙을 "보유" 하고 어떤 작업이 허용됩니까?
일관성 모델. 돈을위한 강력한/CP, 상점을위한 EC/인과 관계.
저장 및 인덱스. 불변 및 SLO 용으로 선택되었습니다.
계약을 종료합니다. 이벤트/명령, 스키마 버전, 전달 SLO.
외부: 직접 SQL/테이블 종속성이 없습니다. 커뮤니케이션-계약을 통한.
6) 경계와 일관성 (PACELC)
BC 내부: 불변량에 대한 모델을 선택하십시오 (Wallet-Strong, Betting-Strong at the Receition).
BC 사이: 대부분 사건과 전망을 통해. 동기식 검증이 필요한 경우 사용할 수없는 마감일과 실패가있는 명시 적 명령 ("숨겨진" REST 통화가 아님).
7) 반부패 계층 (ACL)
ACL의 임무는 BC 내부에 다른 사람의 언어와 더러운 데이터를 허용하지 않는 것입니다.
스키마 매핑: 외부 'PaymentStatus = SETTLED' → 내부 'LedgerEntry (유형 = 크레딧, 이유 = PsPSettle)'.
검증 및 강화: 불변량 검증, 체크 정규화, 통화.
버전: 'schema _ version' 외부 계약 지원, 이전 버전과의 호환성.
이데올로기: 'external _ id '/' operation _ id'.
관찰 가능성: '유독 한' 메시지에 대한 추적 태그 '소스', '스키마 _ 버전', '매핑 _ id', DLQ.
8) 경계 및 데이터: 소유권, 예측, API
소유권: 누가 "진실" 을 소유합니까? 소유자 만 레코드를 변경합니다. BC의 나머지 부분-읽기 모델 및 링크.
투영: 판독을위한 비정규화 된 테이블; 이벤트에서 업데이트됩니다.
API: 명령 (소유자에서 돌연변이) 및 요청 (프로젝션 읽기). 다른 사람들의 데이터에 대한 "엔드 투 엔드" 업데이트는 없습니다.
9) 진화와 버전
이벤트 및 API-' schima _ version '및 호환성 정책 (추가 + 대체).
BC의 Blue/Green: 새로운 계약 'v2' 가 'v1' 과 병렬로 게시되고 트래픽이 점차 이전됩니다.
마이그레이션: 주요 변경 사항-새로운 프로젝션/서비스, "2 단계 판독 스위치".
10) 경계 테스트
계약 테스트: BC가 게시 된 계약 (생산자 테스트) 을 준수하는지 확인하고 다른 사람 (소비자 테스트) 을 올바르게 이해합니다.
재산 기반: BC 내 골재 불변 (균형, 한계, 독창성).
통합에 대한 혼돈: 지연, 고장, 중복, 스키마 진화; DLQ의 존재 및 안전한 재 드레이브.
NFR 테스트: 테두리에서 p95/피크로드 (이벤트 서버/ACL).
11) 경계 별 관찰 및 SLO
메트릭: 이벤트/명령의 처리량, '투영 _ lag _ ms', 'dlq _ rate', 매핑 오류, p95 API.
추적: 필수 태그 'bc', 'tenant _ id', 'event _ id', 'operation _ id', 'skima _ version'.
경고: 투영 지연을 초과하고 명령 오류가 증가하며 스키마 "플랩" (많은 '스키마 _ 불일치').
12) 멀티 테넌트 및 지역
'테넌트 _ id' -국경에있는 모든 사건과 투영의 열쇠에 있습니다.
공정성: 이웃의 SLO를 탈선시키는 것으로부터 "잡음" 을 유지하기 위해 임차인 당 게시/재 추첨 제한.
거주지: BC 데이터는 "가정" 지역에 산다. 지역 간 집계/보고서.
13) 패턴 방지 (경계가 흐려짐)
거대한 "핵심 서비스. "한 곳의 모든 것이 → 거래, 장기 릴리스, 낮은 자율성에 대한 투쟁.
표 통합. 외국 테이블에 대한 SELECT 라인 → 계획에 따른 취약성 및 커플 링.
이중 쓰기. 동시에, "편의를 위해" 두 개의 BC로 작성하면 불일치와 불변의 방해 행위가 발생합니다.
기본적으로 순응. "다른 사람의 모델을 그대로 받아 들였다" → 다른 사람들의 의미의 누출, 진화의 불가능성.
숨겨진 동기 통화. 명시 적 계약 및 마감일없이 "내부 어딘가" REST 호출 → 가용성에 대한 예기치 않은 의존성.
14) 윤곽의 예 (언어 체계)
[Wallet/Ledger] <--CP, Leader, Transactions-->
publishes: WalletReserved/Committed v
[Betting] <--CP on bid taking-->
events: BetPlaced/Settled v
[Read Models/Analytics] <--EC projection-->
[Payments] --ACL--> [Wallet/Ledger]
[Provider Integration] --ACL--> [Game/Round]
[Compliance] <-events - [KYC/Identity], -> reports [Reporting]15) 국경 선택을위한 미니 가이드
1. 불변을 공식화하고 누가 보장 할 수 있는지 결정하십시오.
2. 사전 (10-20 용어) 을 설명하고 팀이 동일한 이해를 갖도록하십시오.
3. 컨텍스트 맵 및 관계 유형을 그립니다.
4. 조인트 안팎에서 일관성 모델을 해결하십시오.
5. 디자인 계약 (이벤트/명령) 및 ACL.
6. 관찰 가능성 (메트릭/추적/경고) 및 DLQ/재 구동 계획.
7. 통합을위한 계약 테스트 및 혼돈을 실행하십시오.
8. 거버넌스 수정: 언어/체계를 소유 한 사람, 변경 방법.
16) 사전 판매 점검표
- 각 BC에는 어휘, 집계 및 불변이 있습니다.
- 관계는 컨텍스트지도에 정의되어 있으며 계약은 문서화되어 있습니다.
- 이벤트/명령 및 ACL을 통한 통합, 직접적인 SQL 종속성 없음.
- 명령/이벤트 demempotency; 아웃 박스/받은 편지함 및 DLQ가 있습니다.
- 일관성 모델 (BC 내부/인터) 이 수정되고 테스트되었습니다.
- 스키마 버전 지정 및 호환성 전략 (v1/v2).
- 래그/오류/성능 지표 및 경고가 구성됩니다.
- 다중 테넌시 및 데이터 레지던트 정책이 시행됩니다.
- 운영 플레이 북: 스키마 불일치, 재 구동, 재건 프로젝션.
17) 빠른 레시피
돈과 한도: BC를 CP 및 거래, API 전용 명령, 독서에 대한 진실의 결과로 분리합니다.
피드/디렉토리: BC, EC, 프로젝션 및 캐시, 명시 적 '신선도'.
항상 ACL, 이벤트/명령, 스키마 버전 지정을 통해 외부 제공 업체와의 통합.
팀 성장: 하나의 BC는 하나의 팀이며, 팀에는 "언어 소유자" 와 "불변의 골키퍼" 가 있습니다.
모놀리스 리팩토링: 먼저 수축 및 ACL, 물리적 분리.
결론
경계 상황은 다이어그램 일뿐만 아니라 언어, 규칙 및 진화 방식에 대한 작업 계약입니다. 명확한 경계는 연결성을 줄이고 속도를 변경하며 시스템을 예측 가능하게 만듭니다. 의미와 불변으로 분리하고, ACL 경계 및 계약을 보호하고, 지표로 모든 것을 측정하며, 도메인과 팀의 빠른 성장에도 불구하고 아키텍처는 유연하고 신뢰할 수 있습니다.