CQRS Journey Guide 톺아보기

우선 나오는 개념들 정리하면..

 

Bounded Context

1. 각각의 Domain Model을 포함하고있는 일종의 문맥이기도 하면서 유비쿼터스 랭귀지를 포함한다.

 

2. Bounded Context는 일관성을 보장해야하는 하나의 개념적 단위, 컴포넌트로 볼 수 있다.

 

3. Bounded Context는 보통 사건(Event)을 발생시켜 다른 B.C.와 통신한다

 

Context Map

1. B.C. 간의 관계를 그리는것으로 접점을 설명하고, 의사소통의 수단으로 사용된다.

 

2. 각각의 서로 다른 B.C. 간 어떤 관계를 갖고있는지, 어떤 상호작용을 하는지 알 수 있도록 하는것이 목적이다.

 

3. Context Map은 상호 교류하는 시스템의 목록을 제공하고 팀 내 의사소통의 촉매 역할을 한다.

 

Command

1. 시스템 내부의 상태를 바꾸는 행위에 대한 요청을 말한다.

 

Event

1. 시스템에서 과거에 발생한 어떠한 사건을 의미한다.

 

2. 보통 명령의 결과에 의해서 발생되며 Domain Model 안의 애그리거트(Aggregate)에서 이벤트를 발생시킨다.

    * (Aggreagte는 Event Bus를 통해 이벤트를 Publish한다.)

 

Process Manager

1. Aggregate의 동작을 지정하는 역할을 갖고있다.

 

2. Process Manager는 Aggregate가 발생시킨 이벤트를 구독하고 간단한 규칙들에 따라 보낼 명령들을 결정한다.

    * (simple set of rule to determine which command or commands to send)

 

3. Process Manager는 어떠한 비지니스 로직도 갖지않는다. 단순하게 다음에 보낼 이벤트를 결정할 로직만 갖도록한다.

 

---

 

주문/ 예약에 대한 고수준 설계

의문

1. Command Bus 존재하는 이유가 뭐지?

-> command bus는 message driven 형태로 신뢰할 수 있는 message 전달하려고 하는 목적인듯.

-> 그래서 어떠한 반환값도 갖지않는다고 표현함.

 

2. Read Model에서는 Store를 Polling해서 구체화 뷰를 만든건가?

-> 지금 단계에선 따로 뷰 모델이 없고 고냥 저장소에서 조회해서 내려주는거였음.

 

---

 

CQRS Command Validation

1. Write Model을 구현할 때, Commands가 실패하지않도록 노력해야한다

=> 이것은 좋은 UX를 사용자에게 서빙하고, 어플리케이션의 비동기 행위를 구현하는데 훨씬 쉬워진다.

 

2. 그러려면 Error와 Failure 를 잘 구분해야한다.

> Error?

* message가 messaging infra에 의해서 전송에 실패했다.

* db connection 문제로 data를 저장하지못했다.

 

다수의 경우, cloud 환경에서 이러한 에러들은 retry 로직으로 해결할 수 있다.

 

> Failure

* 미리 결정된 실패를 말한다. (즉, 도메인 불변식을 말하는듯)

* e.g. 카드 결제가 실패하면, 사용자에게 다른 카드로 결제해야한다는것을 알려주어야한다.

 

---

 

Task-Based UI

 

1. UI의 디자인과 유용성에 영향을 미치는 중요한 요소는 UI가 나머지 어플리케이션과 어떤 방식으로 통신하는가? 이다.

 

2. 어플리케이션이 CRUD 스타일 아키텍쳐를 기반으로 한다면, CRUD 행위 자체가 UI에 스며들게 된다.

 

3. 개발자가 CRUD 스타일 작업에 집중한다면 아래 이미지에서 왼쪽 화면처럼 구성될 가능성이 높다.

 

첫번째 화면은 사용자 행동에 집중하지않고, 단지 리소스를 CRUD 형태로 다룬다는 의도가 강하게 포함되어있다. (데이터 중심 사고로 UI 잡으면 항상 나오는 화면인듯..?)

따라서, 첫번째화면은 사용자가 어플리케이션이 어떻게 작동하는지에 대한 맥락을 추측하며 사용해야한다. (add, remove가 무슨 버튼인지 어케아냐고~) 대신 기술적 구현은 당근 단순해서 쉬움 ㅎㅎ

 

반면, 두번째 화면은 비지니스적으로 무슨일이 발생할지에 대해 명확하게 보여준다.

 

(리소스 중심 UI, UX에 대해 조심하기.....)

 

이럴때 사용자가 수행하는 Task를 기반하여 UI를 구성한다면 CQRS 패턴을 구현할 때 더욱 쉽게 구성할 수 있다. 아래와 이미지와 같이 말이다.

 

위 이미지는 예약자가 컨퍼런스 좌석 구매 작업을 완료할 수 있는 일련의 페이지들을 보여준다.

 

꽤나 직관적이고 명확한 UX를 갖고있는것을 볼 수 있는데, 이는 CQRS를 활용한다면 command로 쌓인 스토어에서 적절히 만들어주고, read model을 query하여 view를 만들어준다. 당연 내려온 데이터엔 식별값이 존재하니 해당 데이터로 command를 또 보낼 수 있다.

 

위 말을 아래와 같이 표현한다.

> UI 는 write side 에 command 를 보내며, UI 는 read side 로 쿼리하고 DTO 를 수신한 뒤 다시 write side 에 command 를 보낸다

 

 

Contoso Message Type Table

위와 같이 이벤트 Send, Receives를 정리할 수 있겠거니해서 첨부.

해당 팀에서는 아래와 같은 네이밍 규칙을 정했다고함.

• 모든 event는 과거형으로 명명
• 모든 command는 명령형으로 명명
• 모든 DTO는 명사형으로 명명