Event Storming and Implementation Workshop
•Download as PPTX, PDF•
5 likes•958 views
This documents explains how to host an event storming workshop and implement an event-driven system
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Event Storming and Implementation Workshop
Similar to Event Storming and Implementation Workshop (20)
More from uEngine Solutions
More from uEngine Solutions (20)
Event Storming and Implementation Workshop
- 1. 분석 > Event Storming: DDD 를 쉽게하는 방법 • 기존의 유즈케이스나 클래스 다이어그 래밍 방식은 고객 인터뷰나 엔티티 구 조를 인지하는 방식과 다르게 별다른 사전 훈련된 지식과 도구 없이 진행할 수 있다. • 진행과정은 참여자 워크숍 방식의 방 법론으로 결과는 스티키 노트를 벽에 붙힌 것으로 결과가 남으며, 오랜지색 스티키 노트들의 연결로 비즈니스 프 로세스가 도출되며 이들을 이후 BPMN과 UML 등으로 정재하여 전환 할 수 있다. vs. • 이벤트스토밍은 시스템에서 발생하는 이벤트를 중심 (Event-First) 으로 분석하는 기법으로 특히 Non- blocking, Event-driven 한 MSA 기반 시스템을 분석에서 개발까지 필요한 도메인에 대한 탁월하게 빠 른 이해를 도모하는데 유리하다.
- 2. 분석 > 이벤트 스토밍 통한 도메인 모델 도출 • DDD 를 통한 서비스 분석의 과정중, Event First 한 방법은 서비스 분해를 위한 기반 주요 객체들을 도 출 할 수 있는 방법을 제공함 이벤트 도출 (Domain Event) 커맨드 도출 (Command) 결합물 도출 (Aggregate) • 키 비즈니스 이벤트 • OrderPlaced • OrderShipped • 이벤트를 발생시키는 액션 • 데이터 모델 • 이벤트 발생의 출처 • ACID 의 묶음 • AddOrder • ShipOrder • Order • Shipping 과정 이등 록됨 강의 가등 록됨 강사 가매 핑됨 수강 이신 청됨 강의 일정 변경 됨 강의 가 취 소됨 수강 승인 됨 지불 요청 됨 과정 정보 입력 강의 정보 입력 강사 매핑 수강 정보 등록 일정 변경 강의 취소 과정이 등록됨 강의가 등록됨 강사가 매핑됨 수강이 신청됨 강의일 정변경 됨 강의가 취소됨 수강승 인됨 지불요 청됨 수 강 승 인 과 정 정 보 입 력 강 의 정 보 입 력 강 사 매 핑 수 강 신 청 일 정 변 경 강 의 취 소 강의 가등 록됨 수강 이신 청됨 강의 일정 변경 됨 강의 가 취소 됨 수강 승인 됨 지불 요청 됨 강사 가매 핑됨 과정 이등 록됨 강 의 (Cla zz) 과정 (Cou rse) 수 강 (Enr ollm ent) 축 하 메 시 지 발 송강 사 달 력 에 추 가 취 소 안 내 메 일 발 송 변 경 안 내 메 일 발 송 일 정 추 가 일 정 이 추 가 됨 일 정 노 티 발 송 노 티 이 력 단계 핵심 내용 예시이벤트 스토밍 결과
- 3. 분석 > 이벤트 스토밍 통한 컨텍스트 맵 > 서비스간 연계 관계 도출 • DDD 를 통한 컨텍스트 맵 도출을 위해서는 각 이벤트들에 의한 후속 액션과 바운디드 컨텍스트를 도 출하므로서, 모듈 간의 관계성과 관심사 분리 범위를 도출할 수 있다 단계 핵심 내용 예시 정책 도출 (Policy) • 이벤트에 따른 각 서브도메인별 관심사 • 이벤트에 따른 후속 액션 • 회원가입시 환 영 메일 발송 바운디드 컨텍스트 • 모듈(마이크로 서비스)별 연동 관계 표시 • 각 서브도메인 별 관계성 표시 컨텍스트 맵 • 동일한 문맥으로 효율적으로 업 무 용어의 범위 • 하나의 BC 는 하나이상의 어그 리게잇으로 구성 • 어그리게잇과 BC는 마이크로서 비스 분해 단위의 후보 수 강 승 인 과 정 정 보 입 력 강 의 정 보 입 력 강 사 매 핑 수 강 신 청 일 정 변 경 강 의 취 소 강의 가등 록됨 수강 이신 청됨 강의 일정 변경 됨 강의 가 취소 됨 수강 승인 됨 지불 요청 됨 강사 가매 핑됨 과정 이등 록됨 강 의 (Cla zz) 과정 (Cou rse) 수 강 (Enr ollm ent) 축 하 메 시 지 발 송 강 사 달 력 에 추 가 취 소 안 내 메 일 발 송 변 경 안 내 메 일 발 송 일 정 추 가 일 정 이 추 가 됨 일 정 노 티 발 송 노 티 이 력 수강승 인 과정정 보입력 강의정 보 입력 강사매 핑 수강신 청 일정변 경 강의취 소 강의가등록됨 수강이신청됨 강의일정변경됨 강의가 취소됨 수강승인됨 지불요청됨 강사가매핑됨 과정이등록됨 강의 (Clazz) 과정 (Course) 수강 (Enrollment) 축하메 시지발 송 강 사 달 력 에 추 가 취소 안내메 일 발 송 변경 안내메 일 발 송 일정이 추가됨 일정 메일로그 과정개발 강의수강관리 달력 U D Customer/Supplier + Sync Anti-corruption Layer + Mediator 일 정 추 가 Conformist + ChoreographyLegend: 마케팅 수 강 승 인 과 정 정 보 입 력 강 의 정 보 입 력강 사 매 핑 수 강 신 청 일 정 변 경 강 의 취 소 강의 가등 록됨 수강 이신 청됨 강의 일정 변경 됨 강의 가 취소 됨 수강 승인 됨 지불 요청 됨 강사 가매 핑됨과정 이등 록됨 강 의 (Cla zz) 과정 (Co urse) 수 강 (Enr oll me nt) 축 하 메 시 지 발 송 강 사 달 력 에 추 가 취 소 안 내 메 일 발 송 변 경 안 내 메 일 발 송 일 정 추 가 일 정 이 추 가 됨 일 정 노 티 노 티 이 력 과 정 개 발 강의관리 달력 마케팅 수강관리 • 주문 • 배송 • 회원관리 • 주문과 배송의 관계 는 Upstream, Downstram 이며, Conformist 임 이벤트 스토밍 결과
- 4. 분석 > 이벤트 스토밍 통한 컨텍스트 맵 > 마이크로 서비스간의 서열과 역학관계 • DDD 를 통한 컨텍스트 맵 도출에서 서비스들의 서열을 나눌 필요가 있으며, 이를 통하여 API 관리 주 체의 연계 관계와 연동 방법을 설정할 수 있다. 1순위: Core Domain 조직의 핵심 역량. 해당 역량은 아웃소싱이 불가능 한 조직의 생존과 경쟁력 자체인 영역임 예) 쇼핑몰 시스템에서 주문, 카탈로그 서비스 등 2순위: Supportive Domain 기업의 핵심 경쟁력이 아닌, 직접 운영해도 좋지만 상황에 따라 아웃소싱 가능한. 시스템 리소스가 모 자라면 외부서비스를 빌려쓰는 것을 고려할만한 예) 재고관리, 배송, 회원관리 서비스 등 3순위: General Domain SaaS 등을 사용하는게 더 저렴한, 기업 경쟁력과는 완전 무관한 예) 결재, 빌링 서비스 등 Core Domain 간 (높은 서열끼리) 에는 Shared-kernel 도 허용가능하다. 하지만, 중요도가 낮은 서비스를 위해 높은서열의 서비스가 인터페이스를 맞추는 경우는 없을 것이다. 카탈로그 (core) 배송 SaaS (general, 외부서비스) 상품추천 (supportive) conformist Anti-corruption 주문 (core) Shared-kernel
- 5. 설계 > 이벤트 스토밍 결과에서 구현 기술 연동 • DDD 를 통한 서비스 분석의 과정중, Event First 한 방법은 서비스 분해를 위한 기반 주요 객체들을 도 출 할 수 있는 방법을 제공함 요소 구현체 • 도메인 이벤트 클래스 미들웨어/프레임워크 • 카프카 • Rabbit MQ • 서비스 객체 • 레포지토리 객체 • Spring Data REST • RESTeasy • 엔티티 클래스 (ORM) • JPA 이벤트 (Domain Event) 커맨드 (Command) 결합물 (Aggregate) 정책 (Policy) 바운디드 컨텍스트 • 엔티티 클래스의 Hook에 정책 호출 구문 주입 • CDC 를 통한 이벤트 후크 • 마이크로 서비스 (후보) • JPA Lifecycle Hook • CDC (Change Data Capturing) • Spring Boot
- 6. 6 설계 > 서비스간 연동 방안 • 이벤트 스토밍의 결과를 서비스간의 연동 토폴로지와 트랜잭션 처리에 대한 설정의 기준으로 삼음 마이크로서비스간 트랜잭션의 묶음을 어떻게 할 것인가? 배송기사가 없다고 주문을 안받을 것인가? 상품 추천이 안된다고 주문버튼을 안보여줄 것인가? Core Domain 간에는 강결합이 요구되는 경우가 생길 수 있다. 하지만 우선순위가 떨어지는 비즈니스 기능을 위해 강한 트랜잭션을 연결할 이유는 하등에 없다. 재고 (core) 배송 상품추천 (supportive) UI mashup Async Event-driven Eventual TX 주문 (core) ACID TX (2PC) 라이락 스티커 (Policy) 를 어디에 둘 것인가? 강 의 정 보 입 력 강 사 매 핑 일 정 변 경 강 의 취 소 강 의 가 등 록 됨 강 의 일 정 변 경 됨 강 의 가 취 소 됨 강 사 가 매 핑 됨 강 의 (Cl az z) 강 사 달 력 에 추 가 취 소 안 내 메 일 발 송 변경 안내 메일 발송 일 정 이 추 가 됨 일 정 메 일 로 그 강의관리 달력 강 의 정 보 입 력 강 사 매 핑 일 정 변 경 강 의 취 소 강 의 가 등 록 됨 강 의 일 정 변 경 됨 강 의 가 취 소 됨 강 사 가 매 핑 됨 강 의 (Cl az z) 일 정 이 추 가 됨 일 정 메 일 로 그 강의관리 달력 축 하 메 시 지 발 송 강 사 달 력 에 추 가 취 소 안 내 메 일 발 송 변 경 안 내 메 일 발 송 일 정 추 가 메 일 발 송 Orchestration Choreography More autonomy to handle the policy Low-Coupling Originator should know how to handle the policy Coupling is High 마케팅 마케팅
- 7. 설계 > 서비스 분리시 분리 전술 • 기존 모놀로식 서비스를 분리할때 발생할 수 있는 다양한 문제가 발생하며, 이를 위한 분리 전술들을 설계해야 함 Course (Mongo DB) Marketing (File Sys) Class (H2) SME (RDB) Calendar (External) 강사 스케쥴 확인 (REST) 강사 스케쥴 등록 (Sub) 강의 일정 발생 (Pub) MQ (Kafka) 광고 메일 발송 (Sub) …. <<Entity>> Cours e <<Entity>> Clazz <<Entity>> Instructor <<Entity>> Schedule <<Entity>> Notificatio n <<Entity>> Enrollm ent <<Entity>> YetAnother … REST API API Gateway JPA Service Object Generated by Spring Repositories: CourseRepository ClazzRepository InstructorRepository H2 <<Entity>> Course <<Entity>> Clazz <<Entity>> Instructor <<Entity>> Schedule <<Entity>> Notificat ion <<Entity>> Enrollme nt REST API 강 결합된 객체 참조 구조 <<Entity>> Topic 객체 참조 방안 • 참조해야 할 도메인 클래스들의 공통화 Shared Kernel, Maven Repo 등을 통한 공통 모델의 공유: 동일 언어인 경우 유리, 디펜던시 발 생 혹은 중복 모델 개발 : Polyglot 인 경우 유리 • Entity 분리에 따른 원격 객체 (어그리게잇) 참조 Primary Key 를 통해서만 참조 HATEOAS link 를 이용 API 통합 방안 • API Gateway 진입점의 통일 Path-based Routing (기존에 REST 로 된경우 가능) • Service Registry API Gateway 가 클러스터 내의 인스턴스를 찾아가는 맵
- 8. 8 설계 > 레가시 전환 – 스트랭글러 패턴 • Strangler 패턴으로 레가시의 모노리스 서비스가 마이크로서비스로 점진적 대체를 통한 Biz 임팩트 최소 화를 통한 구조적 변화 Strangler application Service Service Service Service Service Service Service … Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Time Monolith Monolith Monolith Monolith … Monolith The Monolith shrinks over time. The strangler application Grows larger over time. • 기존에서 분리된 서비스 영역이 기존 모노리스와 연동 될 수 있도록 해주는 것이 필요. • 그 방법은 앞서 동기/ 비동기 방식이 채용될 수 있음 • 동기 – 레거시로 하여금 기존 소스코드 수정 요인이 높음, 따라서 이벤트 기반 비동기 연동 (CQRS) 추천 Modified from Microservices Patterns, Chris Richardson, Manning, 2018 • CDC (Change Data Capturing) 기능 사용 DB 의 Change Log 를 Listening, Event 자동퍼블리시 하는 툴 Debezium, Eventuate Tram 등이 존재 레가시 시스템 New 서 비스 Event pulisher Event handler Translation layer Messaging client Order event Event channel Anti-corruption layer Ubiquitous language of service Ubiquitous language of monolith
- 9. 9 설계 > 데이터베이스 분리 > DB per Services |5.MSAGoalsandDesignPatterns • 방법 1: Db per svc, API 기반 데이터 참조: • 기존 join sql 참조를 통한 외부데이터 참조를 모두 REST 방식으로 전환. • 기존 코드 수정량이 막대함. • 기존 레거시 전환시 비즈니스에 임팩트를 줄 수 있음 • 그린필드 프로젝트인 경우 (새로운 서비스) 추천 • ERP 같은 참조 데이터량이 많은 경우 구현자체가 불가능 할 수 있음 • 사용할 수 있는 플랫폼 • Composite Services • GraphQL REST
- 10. 10 설계 > 데이터베이스 분리 > Miniservices |5.MSAGoalsandDesignPatterns • Miniservices: 물리적 데이터베이스는 쪼개지 않 고 하나로 두면서 애플리케이션에서 데이터베이 스를 접근하는 권한만 나눔. • Shared db, schema per service • 테이블 관리 권한을 각 서비스 주체별로 분리 • 자치성을 제공 • 각 서비스별 다양한 데이터베이스 제품의 선택권은 포기
- 11. 11 설계 > 데이터베이스 분리 > ES, CQRS, Replication |5.MSAGoalsandDesignPatterns • Replication + db per svc: 각 서비스는 각자의 물리 db 로 완전 분리해주고 대신 각 서비스에서 상호 참조하는 테이블 내용을 복제해주 는 방법. • 복제의 방법과 시점이 이때 중요한데 완전히 같은 포 맷의 테이블 구성의 참조용 테이블을 만들어 주기적으 로 동기화 하는 방법과 원천 데이터의 마이크로서비스 에서 변경이 생김과 동시에 이벤트로 퍼블리시 한 후 수신측 마이크로 서비스가 알아서 자기 입맛대로 이벤 트의 내용을 자신의 디비에 반영하는 방법이 있음. • 이벤트 소싱, CQRS 기법으로 접근하는 최근에 추천하 는 방법으로 이 각 서비스는 각자의 polyglot 한 db 제 품과 테이블 설계 자율성을 가질 수 있는 가장 loose coupled 한 데이터베이스 설계.
- 12. 12 설계 > 데이터 프로젝션 > UI Composition |5.MSAGoalsandDesignPatterns • API Composition • Have your user interfaces directly make API calls and map them to UI controls (e.g., web- based UI using JavaScript to get JSON via HTTP). • API Gateway • Have a server-side aggregation endpoint, or API gateway, which can marshal multiple backend calls, vary and aggregate content if needed. • Backends for Frontends • Restrict the use of the backends to one specific user interface or application. This makes each service more self-contained and independent with its own UI and own backend. Sam Newman, Building Microservices: Designing Fine-Grained Systems, 2015.
- 13. 13 설계 > 데이터 프로젝션 > Composite Service |5.MSAGoalsandDesignPatterns • 데이터 통합을 수행하는 별도의 추가적 마이크 로 서비스를 개발함 • 하나이상의 마이크로서비스를 호출한 결과를 하나의 데이터 (JSON) 로 융합하여 리턴하는 코드를 작성 • 데이터 전환 등의 작업을 동반할 수 있음 • 여러서비스 호출의 결과를 기다려야 하기 때문 에 블로킹이 발생 메모리 사용이 높아질 수 있음 • 호출된 하나의 서비스가 성능이 느린 경우 장 애 전파가 발생 가능 • GraphQL 서버를 컴포지트 서비스로 대체하면 프로 그래밍 없이 얻고자 하는 데이터 결과를 GraphQL 방 식의 파라미터로 받아서 하나 이상의 마이크로 서비 스 결과를 융합 조회할 수 있음 Modified from Microservices Patterns, Chris Richardson, Manning, 2018 ≪aggregate≫ Charge Accounting Service ≪aggregate≫ Delivery Delivery Service ≪aggregate≫ RestaurantOrder Kitchen Service ≪aggregate≫ Order Order Service Find Order Composer GET/orders/ {orderId} GET/tickets? orderId= {orderId} GET/deliveries? orderId= {orderId} GET/charges? orderId= {orderId} GET/order/{orderId} Order status view Order id : 3492-2323 Restaurant : Ajanta Status : En route ETA : 6:25 PM Payment : Paid Order status frontend
- 14. 14 설계 > 데이터 프로젝션 > ES, CQRS, Multiple Read Models |5.MSAGoalsandDesignPatterns • 로컬 데이터베이스에 조회하고 싶은 데이터 모 델을 준비함 • 하나 이상의 데이터 소스가 변경될 때 마다의 이벤트를 수신하여 자체 데이터베이스에 반영 함 • 참조하고자 하는 데이터 원본 테이블의 구조와 관계없이 자체 마이크로서비스가 원하는 형태 로 데이터를 적재함 • 자체 데이터베이스를 참조하기 때문에 데이터 참조에 블로킹이 발생하지 않음 • 자체 데이터베이스 레이아웃을 사용하기 때문 에 Polyglot Persistence 를 통한 자치성이 높음 Order Service Kitchen Service Delivery Service Accounting Service Order Service Order history view database Order Events Ticket Events Delivery Events Accounting Events findOrderHistory( ) findOrder( ) Event handlers (Materialized View) Modified from Microservices Patterns, Chris Richardson, Manning, 2018
- 15. 설계 > 접근별 비교 분석 |5.MSAGoalsandDesignPatterns 비교항목 Composition by UI Composition by API Composition by ES, CQRS, Materialized View 블로킹 발생 No Yes No UI 구현 복잡성 High Low Low Latency Mid High Low Configuration 복잡도 Mid Low High 리소스 사용 Low/High High Low