[1]
- kafka=EDA, eventual transaction=eventual consistency(중요) 잠깐 불일치, but 결국엔 일치
- DDD 이벤트 스토밍(중요)
- composition
- Keycloak
- AKS, ACR / EKS, ECR
- polyglot(다형성)
- 쿠버네티스의 무정지배포
- Agile
- 제프베조스
- CQRS
- HTTP/REST vs Asynchronous streaming, message(Kafka)
[2]
- MSA의 문제점: 분산트랜잭션(데이터 일관성 등) 보장, 여러 서비스의 보안처리, 테스트 복잡도 상승
- cncf.io/projects 졸업한 프로젝트 = 명예의 전당이다
- 장애전파 차단: 1. 서킷브레이커 패턴, 2. EDA(kafka) pub,sub - event queue
- req/res Application vs Event-Driven Application
- saga 패턴 (redux-saga와 유사한 듯)
- 3. BizDevOps
- 도메인 서열: core-supporting-general
[3]
- 이벤트 스토밍은 DDD를 쉽게 하는 방법이다. vs 전통적 분석/설계(UML, ERD)
- 퍼실리테이터
- 이벤트 스토밍의 구성
0> Domain Event(주황): 발생한 사실, 결과, Output, 첫 단추, 과거형(p.p)
이는 kafka 큐에 전달
ex) 재고 소진된(상품), 주문 시작된(주문), 배송 지연된(배송) -> 조회는 이벤트가 아님!
1> 빅 픽쳐
1. Hot Spots(핫핑크)
2. Systems(분홍): 시스템 호출 암시(REST)
3. People(노랑): User ex) 고객, 손님 - Commands를 유발하는 주체
2> 프로세스 모델링
1. Policies(라일락): 이벤트에 대한 반응(sub - 구독해온다는 개념) ex) 주문 시작된(주문)의 이벤트와 배송 시작된(배송)
이벤트 사이에 존재하는 배송 시작 Policies
2. Commands(파랑): 이벤트 발생, API, UI버튼, 현재형, Input ex) 주문했다, 배송시작했다 ...
3. Read Models(초록): 의사결정에 필요한 자료, View, UI ex) 고객이 검색하는 상품
3> 소프트웨어 디자인
1. Aggregates(노랑): 비즈니스 로직 처리의 객체 덩어리(하나 이상의 엔터티 및 value 객체의 집합체)
ex) 주문관리 Aggregates, 배송관리 Aggregates
* 여기서 Bounded Context -> 주문은 core, 배송은 support
* Commands 이벤트를 발생하는 것(능동), Policies는 이벤트가 발생했을때 발생하는 것(수동)
[4], [5]
- 이벤트 스토밍 그리기 실습
프로세스 레벨: 그림그리기
디자인 레벨: attribute(aggregate), sync attribute(event)