DDD와 이벤트 스토밍

===

Aggregate하나로 서비스를 구성할 수 있다.

Aggregate는 테이블 여러개의 공통된 특성이다. msa서버의 단위다.

msa에선 그 서버에 DB를 따로 갖고 있어서 다른거랑 join은 안돼 db는 api로 찔러서 하기 때문

 

도메인 = Aggregate

도메인이 변하는게 도메인이벤트, 커맨드에 의해서만 변할수 있다, 도메인이 갖고있던 데이터가 변화되는 것, 수정, 삭제

출력은 도메인이벤트가 아니라 리드모델 - 프론트엔드가 표현해야할게 명확해진다

https://tech.junhabaek.net/ddd-%EC%A0%84%EB%9E%B5%EC%A0%81-%EC%84%A4%EA%B3%84-event-storming-%EC%A0%81%EC%9A%A9%ED%95%B4%EB%B3%B4%EA%B8%B0-%ED%9B%84%ED%8E%B8-aggregate-read-model-bounded-context-6e0f7c8233fb

===

https://youtu.be/hUcpv5fdCIk

https://rok93.tistory.com/170

 : 누군가 정리해놓음

 

DDD : DOMAIN-DRIVEN DESIGN, 도메인 주도 설계

도메인 : 소프트웨어로 해결하고자 하는 문제 영역  예)온라인상의 제품판매

 

이벤트 스토밍 : 복잡한 비즈니스 도메인을 빠르게 탐색하고 학습할 수 있는 워크숍

클래스와 데이터베이스가 아닌, 이벤트와 비즈니스 프로세스에 중점을 둠, 코드를 없앰.

비즈니스 프로세스 를 이해하는 게 목적

 

첫번째 도메인 이벤트.

이런게 도메인 이벤트, 

이벤트가 발생한다는 것은 상태가 변경되었다는 것을 의미한다

바운디드 컨텍스트 : 같은 용어라도 의미가 다를 때, 이렇게 구분되는 경계를 갖는 컨텍스트

바운디드컨텍스트 내에서 정의되는 언어를 유비쿼터스 언어라고 부름

바운티드 컨텍스트까지 했으면 실제 프로세스가 어떻게 일어나는지,

커맨드 또는 액션이라고 불리는 파란색 포스트잇을 사용함

커맨드는 도메인 이벤트가 발생하는 원인이며, 시스템에서 일어나는 일을 표현한다

▽시스템에서 일어나는일인데 사용자가 액션을 취해서 시스템에서 변화가 일어나도

예를 들어 수강생이 등록될 때마다 수강생 등록 정책은 수강신청 성공 메일을 발송한다

https://github.com/kgrzybek/modular-monolith-with-ddd/issues/38

 : 다른 일이 일어날 때 명령을 시작하고 싶을 때 쓰는 것

이런식, 강의가 생성될 때, 시스템적으로 미션생성, 강의생성이 되고, 그걸 도메인이벤트로 표현하면 강의가 생성되었다.

속성 예)장바구니의 합계는 각 상품수량에 단가를 곱한 값, 상품이 바뀌더라도 이 식이 깨지면 안된다

실제로 주어진 클래스들의 제약을 정의하는 방법, 내부의 구현은 자유롭게 할 수 있다

비즈니스 규칙이라고 표현을 바꿀 수 있다

강의, 결제시도, 결제 3개의 Aggregate로 이뤄져있다

- 강의를 듣는 수강생의 수는 정원을 넘을 수 없다

- 결제시도는 시도중, 결제 성공, 결제 실패 중 하나의 상태만 갖고 있어야 한다

- 환불금액은 전체 결제금액보다 클 수 없다

 

===

https://youtu.be/F7EnW8dfetU

 

===

마이크로서비스를 위한 DDD

 

DDD : 디자인패턴, msa에서 잘 쓰여

실제 비즈니스 도메인을 우리가 만드려고 하는 아키텍처에 투영하게 해서 도메인을 정의하고

그걸바탕으로 커뮤니케이션할 수 있는 툴

 

기획, 설계, 개발이 동일한 언어를 쓰게 해서 커뮤니케이션비용을 최소화

(서로 용어를 모르니 문제가많다, 모두가 모여서 하나의 장소에서 공유하면 훨씬 더 효과적),

향후 변경사항이 있거나 할 때 문제해결 싸이클을 작게 가져갈 수 있다

 

DDD를 쉽게 할 수 있는 액티비티 중에 하나가 이벤트스토밍,

msa를 좀 더 명확하게 파악할 수 있다, 최근에는 필수적으로 앞단에서 일어나는 액티비티다

포스트잇으로 하는 이유는 언제든지 변경될 수 있으니 뗐다 붙였다 하기 위함

 

주황색 - 사용자가(상태바뀜, 알림) = 과거형, 수동형 = 아이템이 카트에 들어감.

파랑색 - 이벤트를 일으키는 커맨드(request or trigger), 이 커맨드가 있어서 이 이벤트가 일어나게 된 것

노란색 - Aggregate, 속성을 가진 애, 상품 같은것, '회원'같은 클래스

아이템을 장바구니에 넣는 명령을 내린다 -> 어떤 상품(Aggregate에 영향을 미쳐서 -> 아이템이 장바구니에 들어감

 

*노랑과 주황 = Item과 ItemAdded to Cart는 항상 같이 일어남

 

주황색이 일어나면 노랑색에도 state change가 있다, 반대도 마찬가지

파랑과 주황색도 하나의 짝

 

빨간색 : 이벤트가 일어났을 때 혹시 필요한 외부시스템이 있으면

 

Boris 다이어그램 : 테크니컬한 인플리멘테이션. 노란색 간에 통신, 빨간색도 써주고

 

SnapE : 상세 스펙 정리, 이 서비스는 어떤 api, 어떤 데이터 액세스,

 

===

커맨드와 이에 따른 이벤트 예시)

사용자생성링크선택(파랑) : 이때 해당 화면이 나옴

> 사용자 생성 정보 입력됨(클라이언트가 키보드로 입력하는 그것)

> 사용자 생성 요청함(커맨드를 날림)

(▽> user(Agg) : 이 노랑이 있어야하는 것 아냐?)

> 새로운유저가등록됨

...

 

로그인은

아래처럼 가져오는게 여러개면 위에처럼 줄줄이 나열하면 됨

=======

중간멘토멘토링)
이벤트스토밍, DDD을 하는 이유 : 6명 모두가 도메인에 대한 이해를 확실하게 하기, 문제가 발생하면 커뮤니케이션비용이 있는데 그게 적어짐
막연하게 생각하는게 아니라
이게 다 이해가 된 다음에

▽이벤트스토밍 -> 코드 순서 생각하면서 하면

aggregate : 이게 뭐하는지 보면

=======

▽파랑과 주황을 구분하는 법은 

예시2)

 

==============

이벤트스토밍 두번째, 그루핑

3가지 정도를 고려해서 그루핑을 하는데

- 데이터오너십 : 어떤팀이 어떤 데이터를 가져가냐

- 서비스 단위 그룹의 배포주기를 독립적으로 가져갈 수 있는지

- 독립적으로 확장하거나 축소할 수 있는지

 

보통 첫번째로 고려를 많이 함

보면 중간에 알림을 빼는데 알림 서비스가 따로 있으니까 저렇게 빼는건가..?

굳이 뺄 이유가 있나 모르겠네 저기에 알림이 들어가야한다 써두면 좋은 것 같은데

 

여기까지가 이벤트 스토밍, 서비스에 대한 후보들을 정한 것이다.

 

==============

Boris 다이어그램

 

서비스에 대한 후보들을 정했으니 얘네의 상관관계를 정할 수가 있다

그게 Boris, 서비스와 서비스 사이의 요청을 동기로 할건지 비동기로 할건지 정함

 

주로 Aggregate를 기준으로 함. 어떤 서비스를 할 때 어떤 서비스 정보가 필요하다 하면 선을 긋는것

==============

보리스가 끝나면 각각에 서비스에 대해 SnapE 라는 과정을 진행함, 상세 스펙등을 정하기 위해

API / Data / user-story / RISK / UI

를 정리함

API

주문이면 주문에 대한 API를 생각해보는 것

전체정보를 가져오는 GET /orders

매수 POST /buy

매도 POST /sell

...

 

Data

주문은 Data를 주문이라고 하는 Aggregate를 사용 ▽Aggregate가 테이블인가 하는 내 상상력이 맞는듯

 

user-story

뭐로서, 내가 뭐가 필요한데, 어떻게 하면 된다 로 정리가 됨

간략하게는 매도 요청했다, 매수 요청했다, 회사이름으로 주식검색했다. 이런것

 

RISK

부하, 지연 같은 것에 대한 고민, 어떻게 대처할것이냐를 위함