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

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

 

쇼핑몰 서비스

이 쇼핑몰 서비스는 상품을 판매하는 사람과 구매하는 사람을 이어주는 서비스입니다. 이 서비스는 판매자가 상품을 온라인으로 팔기 위해 쇼핑몰 서비스에 상품을 등록합니다. 이 상품이 필요한 사람이 상품을 주문하면 판매자는 구매한 사람에게 상품을 배송합니다.

이후 구매자가 상품을 받으면 구매를 확정하는 일반적인 쇼핑몰 서비스입니다. 이 서비스의 사용자는 상품 판매자와 상품 구매자로, 상품 판매자는 판매하고자 하는 상품을 쇼핑몰 서비스에 등록합니다. 판매가 된 상품을 구매자에게 발송하는 업무 그리고 상품 구매자는 상품 판매자가 등록해놓은 상품을 구매합니다. 상품이 도착하면 최종 구매를 완료하게 됩니다.

이벤트 스토밍은 도메인의 이벤트를 찾는 것으로부터 시작합니다. 이 도메인 이벤트를 찾을 때에는 시스템에서 발생하는 가장 중요한 이벤트를 찾는 것에 집중을 해야 됩니다. 즉, 데이터나 데이터의 구조를 어떻게 찾고 구상할 것인지가 아닌 쇼핑몰 서비스의 비즈니스 프로세스에 최우선적으로 초점을 둬야 한다는 것입니다.

이렇게 해서 도메인 이벤트를 찾으면 오렌지색 스티커에 찾은 도메인 이벤트의 이름을 적습니다. 도메인 이벤트의 이름은 과거시제의 동사 형태로 작성을 합니다. 예를 들면 account registered, account changed 그리고 purchase requested같이 작성합니다.

팀에 모두가 참여해서 찾은 도메인 이벤트는 모델링 공간의 왼쪽에서 오른쪽으로 시간의 순서대로 붙여나가게 됩니다. 왼쪽에서 오른쪽으로 도메인 이벤트를 찾아 붙이다가 종종 몇 개의 도메인 이벤트는 다른 도메인 이벤트와 동시에 발생하는 경우도 생기게 됩니다.

이런 경우에는 동시에 발생하는 도메인 이벤트를 같은 시점에 발생하는 도메인 이벤트의 아래쪽에 붙이게 됩니다. 팀 전체가 도메인 이벤트를 찾아 시간의 흐름에 맞게 붙여나갑니다. 시스템이 어떻게 동작하는지에 대해 정확히 알 수 있게 됩니다.

 

 

도메인 이벤트

먼저 쇼핑몰은 상품 판매를 위해 판매할 상품을 등록하는 것이 먼저 필요합니다. product registered를 주황색 스티커에 작성해서 모델링 공간에 붙입니다. 그리고 상품을 구매하는 사람에게 상품 정보를 상세히 제공해줘야 합니다. 상품의 상세 정보를 입력하는 product details updated를 작성해서 붙이게 됩니다.

이렇게 쇼핑몰을 통해 판매할 물건이라는 것을 상품, 즉 product라는 용어를 사용했습니다. 이렇게 모두가 사용을 위해 정의한 언어를 유비쿼터스 언어로 정의한 것입니다. 유비쿼터스 언어로 정의하는 것이 중요하다는 것을 계속 기억하면서 진행을 하시면 됩니다. 

쇼핑몰에 상품이 등록이 되면 이 서비스를 통해 상품을 구매할 수 있는데, 상품을 구매할 수 있는 회원이 필요하므로 account registered를 작성해서 모델링 공간에 붙입니다. 회원가입 후에는 상품을 구매하고 결제를 할 수 있어야 하니까 purchase registered와 다음 payment approved를 작성해서 붙입니다.

이 부분을 보면 payment approved와 payment declined가 세로로 가까이 붙여져 있습니다. 같은 시점에 발생하는 이벤트라 세로로 배열해서 붙인 것입니다. 물건을 구입한 고객은 구매한 상품의 배송 상태를 알고 싶어 합니다. 그리고 판매자도 배송이 어떻게 진행되고 있는지 알고 싶어 할 것입니다.

최종 상품이 고객에게 전달되면 고객은 구매확정을 할 수 있어야 하므로 purchase confirmed를 작성해서 붙입니다. 이외에도 가입한 정보 수정이나 탈퇴, 구매한 제품의 수량 변경, 반품, 후기 작성 등 다양한 기능의 제공을 위해 account changed, quantity changed, product returned의 이벤트를 찾아 모델링 공간에 붙입니다.

등록된 상품을 회원이 구매하고 결제하고 배송을 통해 상품 구매가 완료되는 것까지 간단한 쇼핑몰 서비스의 기능이 잘 정의되고 있는 것을 볼 수 있습니다. 이렇게 도메인 이벤트를 찾는 중에 한 단계 또는 여러 단계의 실행 프로세스를 호출하는 경우 그리고 어떤 경우는 외부 시스템과의 연결을 통해 진행되는 경우도 찾을 수 있습니다.

이런 경우 프로세스 또는 외부 시스템의 이름을 연보라색 스티커에 적어서 이 프로세스나 외부 시스템을 발생시키는, 즉 호출하는 도메인 이벤트 스티커 근처에 붙이고, 도메인 이벤트에서 화살표로 표시를 해서 특정 이벤트가 호출하고 있음을 표시합니다. 만들려는 쇼핑몰 서비스에서는 회원이 가입될 때 그리고 회원 정보가 수정될 때 고객 정보를 별도 프로세스를 통해 인증하게 됩니다.

account registered와 account changed 이벤트가 사용자 정보를 인증해주는 별도의 프로세스인 validation check 프로세스를 호출해서 처리한다는 것을 표시합니다. 이 인증 프로세스는 호출을 통해 처리를 하고 있습니다. 그러나, 추후 개발로 전환을 하게 되는 경우 연보라색 스티커는 제거합니다. 사용자 정보 인증에 대한 도메인 이벤트를 찾아 기능을 구체화합니다.

또한 신용카드로 상품 금액을 결제하는 경우 신용카드 결제 시스템에 결제 정보를 보내 결제 승인을 요청할 수 있습니다. 그리고 상품 구매 후기 등록을 하면 멤버십 포인트를 제공하게 됩니다. 이는 외부의 포인트 시스템과 연계해서 제공하는 기능으로 해당 내용을 마찬가지로 연보라색 스티커에 작성을 해서 붙입니다.

이렇게 도메인 이벤트 그리고 실행 프로세스나 외부 시스템을 찾는 과정에서 참여자 간 궁금한 점이나 의견의 조정이 필요한 경우가 많이 발생하게 됩니다. 예를 들면 ‘구매할 때 어떤 정보들이 필요하지?’, ‘신용카드 결제 프로세스를 연계하기 위해서는 더 많은 정보들이 필요한 건 아닌가?’라는 의문사항이 생길 수 있습니다.

그런데 이런 것들이 금방 정리가 되지 않는 경우도 많이 발생합니다. 이런 논의에 많은 시간을 사용하는 대신 눈에 잘 띄는 자주색 스티커에 이런 문제에 대한 내용을 작성합니다. 논의가 되고 있는 곳에 붙여 모두가 이 영역에 해결해야 할 문제가 있다는 것을 알 수 있습니다. 추후 문제가 해결되면 이 자주색 스티커는 제거합니다.

 

 

핫 스팟

쇼핑몰 서비스에서는 7개의 핫스팟이 도출되었습니다. account removed는 회원 탈퇴를 수행하는 이벤트로 회원 탈퇴 후 재가입에 대한 룰이 있어야 된다는 의견이 있어서 자주색 스티커로 표시를 했습니다. payment request approved는 신용카드 결제 서비스로 결제를 요청해야 되는 이벤트로 결제를 요청할 때 필요한 데이터를 빨리 확인해야 된다는 의견을 표시한 것입니다.

그리고 신용카드 결제 시스템을 연계한 경험을 바탕으로 신용카드 결제 요청에 대한 결과가 오래 걸립니다. 이 속도에 대한 개선 방안을 미리 찾아내야 한다는 메시지도 표시를 하였습니다. 그 외에도 다양한 확인할 사항이나 문제점, 의견을 화면과 같이 자주색 스티커에 표시하였습니다.

팀원 전체가 핫스팟을 찾음으로써 프로세스 상 문제가 발생할 것 같은 지점이나 문제 해결을 위한 사전 노력이 필요한 지점을 팀원 모두가 공유하고 인지할 수 있게 됩니다. 특히 깊은 수준의 설계나 구현을 진행하면서 발생되었습니다. 큰 변경이나 재설계가 될 수 있는 것들을 사전에 찾아 조치하거나 조치를 할 수 있게 해주게 됩니다.