마이크로서비스 : 쇼핑몰 서비스 : 세번째 설계 이야기

마이크로서비스 : 쇼핑몰 서비스 : 세번째 설계 이야기

 

엔티티 / 애그리게잇

이 entity라는 것은 이벤트 수행 결과를 표현하는 데이터, 저장하는 데이터입니다. 이 entity aggregate 이름은 노란색 스티커에 작성해서 command과 도메인 이벤트 짝의 위쪽에 살짝 겹치도록 붙이게 됩니다. 이렇게 command, 도메인 이벤트에서 entity aggregate을 찾는 동안 새로운 도메인 이벤트를 발견할 수 있습니다. 이런 경우도 발견하는 즉시 모델링 공간 내의 흐름에 맞는 위치에 작성해서 붙이면 됩니다.

change account command와 account changed 도메인 이벤트의 account에 대한 변경 요청과 변경이 수행되었다는 이벤트의 짝으로 account로 작성해서 붙일 수 있습니다. 마찬가지로 request purchase와 purchased requested 짝은 purchase로 작성해 붙입니다. entity aggregate을 정할 때에는 여러 개념을 두루 포함하는 모호한 표현의 사용을 지양합니다.

command와 도메인 이벤트를 통해 수행된 결과를 명확히 표현하는 작은 범위의 구체적인 명사형의 단어를 찾는 것이 중요합니다. 이 모델의 모든 command와 도메인 이벤트마다 entity aggregate을 정의해서 붙여봅니다. 지원 서브도메인으로 식별했던 회원 서브도메인부터 entity aggregate을 정의합니다. register account와 account registered, remove account와 account removed, change account와 account changed의 짝은 모두 account로 정의할 수 있습니다.

핵심 서브도메인으로 식별했던 상품 서브도메인을 진행해보도록 하겠습니다. register produc와 product registered, update product와 product updated의 짝은 product로, set product details와 product details updated의 짝은 product detail로 정의할 수 있습니다. 다른 서브도메인도 앞에 진행한 대로 command와 도메인 이벤트의 짝에 entity aggregate을 정의합니다.

 

 

경계와 흐름

경계와 흐름은 모델링 공간에 경계를 그리고 흐름을 표시하는 활동으로 바운디드 콘텍스트를 나눕니다. 마이크로서비스로의 전환을 위해서 하나의 서비스에 어느 정도의 기능을 넣을지 충분히 고민하고 논의해서 정해야 합니다. 경계는 검은색 마커펜을 이용해서 표시합니다. 이전에 서브도메인은 그 경계를 점선으로 표시했었는데 콘텍스트 간의 경계를 나타내는 바운디드 콘텍스트는 실선으로 표시합니다.

바운디드 콘텍스트를 식별하고 콘텍스트 간의 매핑 관계를 그린 콘텍스트 맵에서는 동기 방식의 흐름은 실선으로 표시합니다. 이벤트를 활용한 비동기 방식의 흐름은 점선으로 표시하여 이 도메인 이벤트의 이름은 점선 옆에 같이 표시합니다.

 

 

바운디드 컨텍스트 식별

일반적으로 하나의 서브도메인은 하나의 바운디드 콘텍스트로 가져갑니다. 그 이상의 서브도메인으로도 식별을 할 수 있습니다. 따라서 진행하고 있는 쇼핑몰 예제는 하나의 서브도메인을 하나의 바운디드 콘텍스트로 그대로 가져갔습니다.

서브도메인과 바운디드 콘텍스트를 같이 표시한 화면을 좀 정리해서 보면, 화면과 같이 바운디드 콘텍스트를 찾아낼 수 있습니다. 식별된 바운디드 콘텍스트의 이름은 앞서 코멘드와 도메인 이벤트 사이의 관계를 표현하는 entity aggregate 이름을 종합해서 정의하였습니다.

회원의 가입과 탈퇴, 회원 정보 수정을 담당하는 바운디드 콘텍스트는 account 콘텍스트. 판매자가 판매할 상품의 등록을 관리하는 콘텍스트는 product 콘텍스트, 상품 구매자가 구매를 위한 상품과 상품의ㅇ 수량을 선택하는 콘텍스트가 있습니다. purchase 콘텍스트 그리고 화면과 같이 payment, delivery, return, review 콘텍스트로 식별을 하였습니다.

동기식의 데이터 흐름은 실선으로, 이벤트를 통한 비동기 방식의 흐름은 점선으로 표시하고, 이벤트의 이름을 점선 위에 표시하였습니다. 변경사항이 동시에 실시간으로 반영이 필요한 경우가 아닐 때는 이벤트로 처리하는 비동기 방식을 많이 사용합니다. 이 비동기 방식은 콘텍스트 간의 불필요한 결합, 즉 dependancy를 제거합니다. 각 바운디드 콘텍스트가 독립된 기능을 갖도록 하는 데 좋은 연동방식입니다.

 

 

마이크로서비스 식별

이 6개의 바운디드 콘텍스트는 화면과 같이 account, purchase, product, payment, return, delivery, review의 7개의 마이크로서비스로 식별을 하였습니다. 그 중 order 콘텍스트가 2개의 마이크로서비스로 나눠서 구성되었습니다. order 콘텍스트의 경우는 많은 상품 판매자를 유치하기 위해 다른 쇼핑몰과 차별화합니다. 구현할 계획으로 지속적인 개선이 발생하고 이에 따른 서비스의 배포가 예상됩니다. 그러나, 결제의 경우는 외부의 결제 시스템 연동으로 지속적 개선이 거의 발생하지 않을 것으로 판단합니다.

굳이 상품 구매 기능의 개선에 묶여 같이 build되고 배포될 필요가 없습니다. order 콘텍스트는 purchase, payment 서비스로 분리해서 별도 서비스로 식별하였습니다. 이로써 쇼핑몰 서비스를 이벤트 스토밍 기법을 통해 큰 그림을 그리고 핵심 프로세스를 찾을 수 있었습니다.

 

 

읽기 모델

워크숍 참여자들은 command와 사용자 사이에 몇 가지 생각해볼 것이 있습니다. 먼저 command은 사용자의 요청을 처리하기 위해 만들어진 것입니다. 좀 더 사용자 요청의 관점에서 생각해볼 필요가 있습니다. ‘상품 구매를 위해 상품을 조회해보고 선택하기 위해서는 화면 왼쪽 상단에는 상품 이미지가 보여야 합니다.

상품 가격은 다른 글자들 사이에서 잘 보이도록 표시되어야 합니다.’와 같이 화면에 보여야 하는 데이터들을 정의할 필요가 있습니다. 사용자의 요청을 처리하기 위한 의사결정을 위한 도구라고 이해하면 좋습니다. 이 read 모델의 내용은 초록색 스티커에 그 내용을 작성해서 모델링 공간에 붙이게 됩니다.

읽기 모델을 찾는 과정, 즉 사용자의 command를 동작시키기 위해 필요한 데이터를 식별하는 과정입니다. 구매자가 구매를 위한 action을 하기 위해 도움을 주는 이 항목들을 찾아내기 위해서는 사용자의 역할과 이 서비스를 이용하는 구체적인 방법과 사례를 이해할 수 있어야 합니다. 그래야 꼭 필요한 데이터를 정의할 수 있기 때문입니다.

좀 더 나아가서 데이터뿐만 아니라 사용자에게 보여질 페이지의 레이아웃이나 유저 인터페이스도 간단하게 스케치를 해서 보여줄 수 있습니다. 이 유저 인터페이스도 스케치의 형식으로 화면의 배치나 꼭 보여져야 하는 것들, 테이블 또는 차트 등의 화면에 보여져야 하는 방식을 표현할 때 사용합니다.

사용자로 인해 동작하는 command, 이 command에 따라 시스템이 어떤 도메인 이벤트를 동작시키는지에 대한 가정이나 특정 사례, 기준 등을 정의할 필요가 있게 되는데 이를 정책이라고 합니다. 정책의 내용은 보라색의 스티커에 작성되며, command과 도메인 이벤트 사이의 정책임을 나타내기 위해 두 스티커 사이에 붙일 수 있습니다.

이 읽기 모델과 정책을 추가로 식별해서 설계 수준으로 더 깊이 모델링을 진행하면 화면과 같이 나타낼 수 있습니다. 사용자의 결제를 요청하는 기능에 대한 것입니다. 설계 수준의 이벤트 스토밍 워크숍을 통해 모델링을 진행한 것을 보여주는 것입니다.

사용자는 스케치한 유저 인터페이스 화면을 통해 결제를 요청할 수 있습니다. 이 요청은 외부의 신용카드 결제 시스템과 연계되는 것을 보여줍니다. 그리고 결제 요청에 대한 결과는 결제 승인과 거부로만 결과를 받을 수 있습니다. 결제 승인 후 배송 정보를 입력하는 사용자의 구매 프로세스를 설계 수준으로 모델링하였습니다.

워크숍을 통해 도출한 바운디드 콘텍스트를 화면과 같이 더 깊은 설계 수준으로 모델링을 수행합니다. 설계가 구현으로 그대로 이어질 수 있게 됩니다. 이벤트 스토밍을 통해 큰 그림과 핵심 프로세스를 찾습니다. 서브도메인, 바운디드 콘텍스트 그리고 마지막으로 마이크로서비스를 도출하는 과정이었습니다.