✅ Domain Event
- 이벤트란? 시스템에서 발생한 과거의 일
- 과거형 동사로 표현한다.
- ex) 회원이 있고, 회원을 등록한 다음에 로그인 과정을 거치게 된다.
- 회원 등록 됨 (과거형으로 표시)
- 로그인이라는 활동을 통해서 발생된 사건이 ⇒ 로그인 됨 이라는 이벤트를 발생한다.
✅ Hot Spot
- Domain Event를 붙이다 보면, 사람들이 알 수 없는 내용이 발생하거나 질문이 생긴다.
- 이런 것들을 Hot Spot 이라고 해서 붙이게 된다.
- 의견 수렴, 질문, 가정이 필요한 내용
- 의문이 드는 내용들, 도메인 지식이 없는 경우, 알아가야 되겠다 하는 부분을 보라색으로 표시한다.
- 관련된 이벤트의 필요한 경우에만 붙이게 된다
✅ Command
- Command는 Domain Event에 쌍을 맞춰서 Domain Event의 왼쪽에 붙이게 된다.
- Command는 Domain Event를 Trigger 하는 역할을 담당한다.
- 현재 동사로 표현한다.
✅ Actor
-
Actor는 Command를 동작하게 하는 어떤 사용자 역할이다.
당연히, 명사여야 한다. (사용자 역할)이다. -
Command 아래에 붙이게 된다.
이러한 경우는 좀 작은 포스트잇을 사용한다. -
“회원 등록 됨“ 이라는 이벤트라고 하면
회원이 회원 등록 Command를 통해서 Domain Event “회원 등록 됨“ 이벤트를 발생시킨다. -
하나의 문장으로 해석이 가능하도록 검증하는 용도로 활용 가능하다.
-
Command와 Domain Event를 제대로 식별했는지 액터를 통해서 검증할 수 있고
교정을 할 수 있다.
Actor를 보통 뽑으라고 하면, Actor는 회원, 사용자 이런 식으로 뽑는 경우가 있다.
근데 그렇게 하면, 어떤 Command를 발생 시키는 것은 다 사용자이고 회원이게 된다.
그렇게 되면 Command나 Domain Event를 검증하는 입장이나 BC에 필요한 개념들을 찾아내기 힘들다.
그래서, Actor는 어떻게 보면 굉장히 구체화 해야한다.
배송이라는 Context에서 “회원”이라고 표현 안하고 “수취자＂라는 역할로 할 수 있었다.
주문이라는 도메인에서 주문을 실제로 하는 사람은 “회원“ 보다는 개념보다는 “주문자＂라고 하는 개념으로 식별할 수가 있었다.
그런식으로 Domain의 Context에 맞는 그런 구체적인 Actor 를 찾는 것이 굉장히 유비쿼터스 랭귀지를 통한 도메인 모델을 도출하는데 도움이 된다.
(구체적인 Actor를 도출하는 것이 중요하다.)
✅ Policy
-
Actor가 도출되었으면 Policy를 도출할 수 있다.
-
Policy가 굉장히 중요한 요소이다.
-
어떤 이벤트가 발생했을때, 그것에 의해 자동화 되어서 다른 Command를 호출하는 정책이다.
-
정책, 시나리오를 Policy라고 한다.
-
특정 관계에서 커맨드가 특정 도메인 이벤트가 발생할 때 자동으로 실행된다 라는 관계가 있을 때 Policy라고 한다.
-
~~ 하면 항상 ~~한다라는 관계를 정책으로 표현할 수 있다. -
예를 들어서
회원 등록 됨 => 로그인 됨사이에서는 자동으로 이루어지는 관계가 아니기에
그러한 관계에서는 Policy를 도출할 수 없다. (자동으로 이루어지는 경우가 아니기에) -
예를 들어 “주문 됨” 이라는 이벤트가 있고 “배송 요청한다.“ Command를 Call 하게 된다.
-
자동으로 주문 이벤트가 발생이 되면 반드시 배송 요청이라는 요청을 호출해야 한다는 비즈니스 규칙이 있다면 그것들을 “정책”으로 뽑을 수 있다.
✅ External System
- 도메인 이벤트랑 연계 되는 외부 시스템 혹은 Legacy 시스템을 External System으로 뽑아내게 된다.
- 예를 들면, 회원가입을 하는데 외부 Oauth2 시스템을 통해서 로그인을 하고자 할때
그런 시스템을 외부 시스템 (External System)으로 표현할 수 있다. - 회원이 등록 되고 나서, 축하의 이메일을 발송하게 된다고 하면
그 이메일을 전송하는 시스템이 외부 시스템이라고 할 수 있다. - 외부 시스템이라서 명사형으로 사용한다.
✅ Aggregate
- 최종적으로 Aggregate 이라는 것을 도출하게 된다.
- Command 와 Domain Event 사이에 위쪽에 노랑색 포스트잇을 붙인다.
- Domain Event와 Command에 의해서 관리되는 데이터라고 한다.
- Domain Event와 Command를 표현하는 키워드라고 할 수 있다.
명사로 표현한다.
1. 도메인 이벤트 도출
- 하나의 흐름을 도메인 이벤트를 가지고 도출한 것이다.
- 조금씩 띄워져 있는 경우는 Command를 붙이기 위해서이다.
2. Hot Spot 식별
- 주문 취소됨이 가능한 시점을 모르는 경우 (도메인에 대한 이해 부족)
- 추후 결정하기 위해 기록
3. Command 식별
- Domain Event를 붙이게 되면 Command 는 쉽게 붙일 수 있다.
- 결제 승인됨, 주문 완료됨, 결제 거부됨 같은 경우는
주문 항목 주문이라는 Command 에 의해서 한번에 실행이 되는 이벤트라서 이렇게 붙이지 않을 수도 있다. - 비지니스 로직에 따라서 달라질 수 있다.
4. Actor 식별
- Actor를 식별하게 된다.
- 회원이랑 관리자 이런식으로 도출하게 되면 추후 BC를 구분하는데 힘들다.
- BC 내에 활동할 그런 Actor 들 역할을 찾아낸다.
- 그 다음 Policy를 식별하게 된다.
5. 정책 식별
- 주문 취소 됨이라는 이벤트가 발생 되면, 반드시 재고 수정이라는 것이 자동으로 되어야 한다.
- 주문 완료 됨이라는 이벤트가 발생하게 되면 이것 역시 재고 수정이라는 것이 자동으로 되어야 한다.
- 이런 경우에 Policy를 도출하게 된다.
- 주문 완료 됨이라는 이벤트가 시작하면 배송 접수라는 이벤트가 자동으로 실행되어야 하는 경우에는Policy를 사용할 수 있다.
- 그 다음에 하는게 외부 시스템을 호출하게 되는 것이다.
6. 외부 시스템 식별
- 결제가 승인이 되고 나서, 이메일을 수신할때, 이메일 시스템이라는 외부 시스템을 호출할 수 있다.
- 그런 연관관계를 외부 시스템으로 도출한다.
- 관계가 있는 도메인 이벤트에 외부 시스템을 붙이면 된다.
7. Aggregate 식별
- 최종적으로 Aggregate를 도출하게 된다.
- Aggregate는 Command와 Domain Event에 의해 관리되는 데이터라고 할 수 있다.
- 데이터적인 요소들을 도출하게 된다.
8. Bounded Context 식별
그 다음에 BC를 도출하게 된다.
최종적으로 식별한 Aggregate를 기점으로 식별하게 된다.
-
BC을 도출하게 되면 각각의 경계가 생긴다.
-
그 BC 경계를 넘나드는 것을 Policy를 통해서 확인할 수 있다.
-
BC 를 넘나드는 Policy가 있다면은 그런 부분들은 Context Mapping을 해야되는 대상이 된다.
-
Context Mapping을 어떻게 할 것인가 (크게는 2개)
- 동기적 관계
- 비동기적 관계 (제일 많이 사용되는 관계)
-
그리고 도출된 BC에서 핵심(Core)이냐 일반 or 지원 Context이냐를 식별하게 된다.
-
그렇게 하는 이유는 만약 주문이 핵심 Context가 되었을때 주문에 대한 설계 전략들을 달리 가져갈 수 있다.
-
BC 도 핵심, 일반, 지원을 나눠서 각기 다른 설계 전략을 가질 수 있다.
-
그렇게 중요하지 않는 부분에 대해서는 외주를 통해서 넘길 수도 있다.
9. 전체적인 Context Mapping
- 각각의 BC 관계를 표현하는 정책들을 비동기적 혹은 동기적으로 설계를 진행할 수 있다.
- BC와 외부 시스템을 표현만 하면 이해하기 힘들기에 Front End를 표현하면 이해하기 수월하다
- Front End와의 관계는 반드시 동기 관계이다.
Ex) 이벤트 스토밍 결과를 헥사고날 아키텍쳐와 매핑하기
- Command는 API 후보가 되는 것이고
- Aggregate는 비즈니스 로직을 표현하는 후보가 될 것이다. (도메인 모델이나 데이터 모델이 될 수 있다.)
- 외부 시스템은 외부와 연계되는 요소들이 된다.
- Domain Event는 각각의 다른 영역과 비동기 통신을 하게 되는 부분이다. (메시지 브로커)
참고
