개요
- 사내 도서 시스템에 대한 요구사항을 분석하여 이벤트 스토밍을 직접 실습해본다
- 이벤트 스토밍 결과로 도메인 모델링을 해본다
- 도메인 모델링 결과에 따라 적절한 비즈니스 로직 구현 패턴과 아키텍처 패턴을 판단한다
사내 도서 시스템 이벤트 스토밍
- 요구사항 정의
- 요구사항 분석 후, 전체 흐름도를 간략히 그리기
- 도메인 이벤트, 핫스팟 도출
- 커맨드 및 액터 도출
- 정책 및 외부시스템 도출
- 애그리거트 도출
- 바운디드 컨텍스트 식별
- 컨텍스트 매핑 정의
- 이벤트 스토밍 결과 예시
1. 회원 및 로그인
2. 도서
3. 도서 대여
- 이벤트 스토밍을 직접 진행해보았을 때 보완이 필요한 개선 사항
- 이벤트 플로우에 대한 모든 동사를 도메인 이벤트로 정의하는 것으로부터 시작됨
- 이벤트 플로우 전체 흐름에서 빈틈이 발생하는 구간에 핫스팟을 정의
- 예시) 첫 연체되면 연체 해지를 못하기 때문에 사용자 최초 등록 시 기본 사용자 포인트가 부여되어야 함
- 요구 사항에 적힌 것과는 다르게 Actor가 다를 수 있음
- “사용자를 등록한다” 라는 의미가 사용자가 회원가입을 하는게 아니라 관리자가 등록시키는게 맞는지, 일반적인 프로세스가 아닌 것은 검토 필요
- 이벤트 스토밍 첫 시작은 액터를 비회원/회원, 관리자, 사서, 대여자, 시스템, 반납자, 연체자 등 세부적으로 나눌 수록 좋다
- 추후 컨텍스트 매핑 단계에서 바운디드 컨텍스트가 구분이 되어질 때 통합되는 의미로 변경해도 좋음
- 정책 정의 후 화살표로 업무 흐름을 정의
- 외부시스템 부분 설명에서는 이메일 시스템이 될 수 있고 이외에 SNS 연동 로그인이나 결제연동시스템이 주가 된다.
- 애그리것 도출은 커맨드와 이벤트 사이에 데이터를 표현하는 명사 단어를 도출하는 것임
- 바운디드 컨텍스트 정의
- 도출된 애그리것을 보고 응집도를 판단
- 바운디드 컨텍스트 간 선을 그어서 구간을 분리
- 통합과 분리의 판단 기준은 데이터 일관성 / 마이크로 서비스 분리에 따른 확장성, 안정성
- “회원 + 권한” / “로그인”
- “도서 관련” - 입고도서~ 베스트도서
- 베스트도서는 읽기 요청이 가장 많이 발생하기 때문에 “베스트도서” 바운디드 컨텍스트를 새롭게 구분할 수 있음
- 이 과정에서 베스트 도서가 되는 정책 내용이 필요함을 발견하게 되면, 새로운 도메인 이벤트 “베스트도서 순위 등록”이 추가되고 이에 따른 정책이 추가 될 것
- “도서 대여”라는 행위에서 파생되는 것들을 하나로 묶음 (도서 대여~ 연체도서)
- 단, 회원 정보에 포함되는 사용자포인트 관련은 회원 바운디드 컨텍스트로 이동 (사용자 포인트, 연체 포인트)
- 도서 상태 정보에 포함되는 애그리것은 또 ”도서 관련“으로 이동 (대여 상태, 연체 상태)
- 바운디드 컨텍스트를 나누다보면 정책 또한 특정 바운디드 컨텍스트에 포함되게 됨
- 바운디드 컨텍스트 정의 후, 핵심/일반/지원 도메인을 구분
- 대여 = 핵심
- 회원 = 일반
- 도서 = 일반
- 베스트도서 = 지원(지원 도메인은 없어도 서비스 흐름에 지장이 없을만한 것)
- 이벤트 스토밍 결과 비교하기
- 정책은 바운디드 컨텍스트 외부에 위치시켜도 됨
- 컨텍스트 매핑
- 바운디드 컨텍스트 간 관계가 있는 것들에 대해 매핑도를 그려준다
- 관계에 대한 선을 이어주고, 관계에 대한 도메인 이벤트를 나열한다
- 바운디드컨텍스트 내부에서 처리되는 것들은 표시하지 않는다
- 외부시스템에 대해서도 그려준다
- 이벤트 호출 방식은 실선과 점선을 사용하여 동기/비동기식인지 표기한다
- 별도의 저장소를 쓴다고 하면, 베스트도서 BC는 조회만 하기 때문에 MongoDB같은 최적화된 DB를 선택하여 조회 성능을 높일 수 있음
이벤트 스토밍 결과 정리 및 도메인 모델링 하기
- 이벤트 스토밍 결과를 헥사고널 아키텍처로 표현하기
- 중심부
- 애그리것
- 도출된 애그리것은 전술적 설계에 의해 나오는 요소인 엔티티, VO, Repository들의 군집이라고 할 수 있다
- 도메인 이벤트
- 컨텍스트 매핑에 의해 외부로 나가는 이벤트를 배치함
- 바운디드 컨텍스트 내부에서 자체적으로 처리되는 도메인 이벤트는 표기하지 않음
- 중간부 : 커맨드
- 각각의 바운디드 컨텍스트는 유연하게 트랜잭션 스크립트, 액티브레코드, 레이어드 아키텍처 등 도메인 타입(핵심,일반,지원)에 따라 적용하여 효율적인 개발 가능
- 회원 도메인 헥사고널
- 도서, 베스트도서, 대여 헥사고널
- 도메인 모델링하기 - 대여 BC
- 대여자/반납자/연체자로 구체화 한 Actor는 같은 바운디드 컨텍스트내에 있기 때문에 구분하는 것은 의미가 없고 통합된 의미로써 대여자를 기준으로 정리 해본다
- Class Diagram을 Lucid Chart를 이용해 UML 그리기
- Entity 정의 - RentalCard
- operation은 end point 로써의 public(+)과 private(-)로 표현
- VO 정의
- 간단한 표현 - Entity와 상태 정도 표현
- 디테일한 표현 - Entity의 모든 속성에 VO 적용
- 컨텍스트 매핑을 통한 외부 호출하는 도메인 이벤트에 대한 클래스 다이어그램 작성
- 도메인 모델링 - 회원 BC
- 위 과정과 마찬가지로 Entity에서 long, string같은 원시 값을 사용할 것인가 아니면 VO로 분리할 것인가에 대한 판단을 하면 된다
- VO의 장점은 유효성 체크
- 도메인 모델링 - 도서 BC
- 도메인 모델링 - 베스트 도서 BC
- 대여BC의 ItemRented 도메인 이벤트가 호출되면서 발생하는 이벤트
설계 의사 결정 및 구현 과정 소개
- 휴리스틱 (경험에 기반한 규칙)
- 바운디드 컨텍스트
- 크기로 경계를 구분하지 않음
- 경계를 넓게 보며 바운디드 컨텍스트 구분을 시작하는 방법이 좋다
- 도메인 지식이 쌓이게 되면 좀 더 작은 경계로 쪼갠다
- 비즈니스 로직 구현 패턴과 아키텍처 패턴을 결정하는 방법
- 테스트 전략 결정
- 피라미드형 테스트
- 단위 테스트 중심 (고전적인 전략)
- 도메인 모델 패턴
- 테스트 비중 : 도메인 모델 테스트가 중점적 > 레포지토리 테스트 > 프론트부터 전체 흐름 E2E 테스트
- 다이아몬드형 테스트
- 통합 테스트에 집중
- 자료구조가 복잡한 케이스
- 레포지토리 테스트 중심
- 액티브 레코드 패턴
- 역전된 피라미드형 테스트
- E2E 테스트에 집중 (API 레이어 테스트 또는 프론트부터 시작되는 테스트)
- 트랜잭션 스크립트 패턴
- 응용 서비스쪽에 서비스 로직이 몰려있기 때문에 단위/통합 테스트를 나누는 것이 의미가 없다
