https://www.youtube.com/watch?v=QUMERCN3rZs
도메인 지향 개발에 필요한 과정인 Event Storming 프로세스를 도출하는 방법을 설명하는 영상을 보고 정리한 내용입니다.
먼저, 도메인이란 유사한 성격을 띠는 비즈니스의 집합이라고 정의해보겠습니다.
거래 서비스 도메인을 개발한다면 Item - Order - Cart 등이 Aggregate가 될수 있습니다.
명시적인 모듈화를 위해 Aggregate가 가져야하는 특성은 아래와 같습니다.
1. 약한 결합도(Loosely coupled): Item, Order, Cart등의 클래스들은, Object referencing 대신 Id referencing을 해야합니다. -> 상이한 Aggregate의 데이터를 가져오기 위해서는, id를 인자로 데이터에 접근하는 방향으로, 객체간의 책임을 명확히 분리합니다.
2. Aggregate과 event는, 한 묶음으로 atomic하다: event의 발생 = Aggregate의 상태변화이다.
-> 각 모듈 내부의 이벤트는, 소속된 모듈 Aggreate 만의 상태변화를 책임진다.
이벤트스토밍 과정은, 각 화면에서 발생하는 이벤트들을 액티비티 다이어그램과 유사한 형태로 플로우를 먼저 나열한 후, 비즈니스 성격에 맞지 않는 프로세스는 분리하여, 새로 모듈을 생성하거나, 유사한 성격의 Aggreate이 존재한다면 성격에 맞게 끼리끼리 이벤트를 모아줍니다.
성격별로 이벤트를 모두 분리하게 되면,
Command(이벤트) - Aggregate - 외부연동시스템
세가지의 요소로 이루어지게 플로우가 정리된다는것을 알수있습니다. 이를 문서화할때는 보리스다이어그램(Boris diagram)을 이용합니다.
이벤트 스토밍 과정에서 고려해야할 Aggreate이 가지는 내부 상세스펙 5가지입니다.
Api, Data, Stories, Risk, UI
분석대상인 Aggreate는
1. 어떤 Api를 가지는가(+ request가 동기/비동기인가)
2. 어떤 Data와 협력해야하는가
3. 어떤 유저스토리를 가지는가(고객의 니즈를 반영한 기능)
4 .연동시 리스크가 존재하는가
5. 어떤 UI, BFF(Backend For Frontend) 와 연동되는가(사용자경험)
Snap- E: 마지막으로 각 모듈을 그룹핑하는 3가지 조건입니다.
1. 데이터 오너쉽: 데이터의 오너쉽을 누가, 어떤팀이 가져가는가
2. 팀의 배포주기
3. 독립적인 Scalibity (확장&축소)
