[배달 중계 서비스#2] 설계

요구 사항 정의

요구 사항 정의는 보통 클라이언트, 비즈니스 담당자, 소프트웨어 아키텍트등의 외부 직군이 개발자에게 전달하는 문서이다.
위에 작성한 요구 사항은 극히 간략화된 요구 사항이다.
간략히 작성한 이유는 개발자인 나 혼자서 진행하는 프로젝트이니 Validation 정책과 중복되는 부분을 생략하고자 하는 의도와, 처음부터 완성된 형태의 서비스를 개발하는 것이 목적이 아니기 때문이다.

ERD

요구 사항을 토대로 테이블을 도출하여 ERD를 설계한다.
서비스의 범위가 크지 않고, MSA 아키텍처의 특성 상 굉장히 단순한 구조로 만들 수 있었다.

만약 복잡한 구조의 프로젝트여서 테이블을 도출하기 어렵다면, 요구 사항에서 명사를 나열해 보거나
와이어 프레임을 만들며 부족했던 정보를 보충할 수 있다.

여기서 잠깐 RDBMS와 NoSQL의 비교를 하자면...

프로젝트의 쿼리 성향을 분석해 보면, save -> update -> update -> update... 로 전체 동작에서 압도적으로 update쿼리의 횟수가 많을 것으로 예상된다.

때문에 불필요한 연관관계를 맺지 않았고, 결과적으로 RDBMS보다 NoSQL에 적합한 환경이라고 볼 수 있다.

또한 RDBMS로 리액티브 스트림을 구현하기 위한 R2 DBC는 MongoDB의 Reactive Streams 드라이버 보다 상대적으로 불안정한 상태에 있다고 들었다. (현재 기준 3.0 버전으로 나름 꾸준히 발전해 왔다고 할 수 있는데, R2 DBC의 현 위치가 어느정도인지는 조사가 필요하다.)

시퀀스 다이어그램

보통 시퀀스 다이어그램을 설계하기 전에 요구 사항을 토대로 기능 설계 마인드맵을 작성하고, 각 기능들을 실행할 때 관련된 테이블에 CRUD 중 어떤 것이 발생하는지 정리하는 기능-엔티티 매핑 설계를 하는 두 단계 프로세스를 먼저 진행한다.
다만 이번 프로젝트는 MSA 구조로 하나의 서비스 당 하나의 도메인 영역을 맡고 있고, 요청에 의해 실행되는 작업이 매우 단순하다. 때문에 두 단계의 프로세스를 스킵하고 바로 시퀀스 다이어그램을 설계했다.

 

시스템의 흐름과 구성 요소들의 상호 작용 방식을 시각화하면 흐름을 놓쳐 고민하는 시간을 덜어낼 수 있고, 전체적인 개발의 템포가 올라간다.

상태 다이어그램

상태 다이어그램은 어떠한 흐름에서 시스템이나 객체의 상태 변화, 상태 간의 전이를 시각적으로 표현하는 다이어그램이다.

여러 분기점이 존재하는 API의 흐름을 시각적으로 이해하고 개발에 들어가는 것은 개발 속도 향상과 실수 방지에 큰 도움을 준다.

주문 승인 API

 

프로젝트 특성상 관리 서버는 주문 생성을 제외하면 모든 API가 위와 거의 동일한 흐름을 가지고 있다.

중계 서버 또한 수신 받은 이벤트를 처리하여 메시지에 담긴 객체를 저장하고, 그것을 조회하는 간단한 구조이니 상태 다이어그램은 필요하지 않다.

 

위치 정보 갱신 API

 

라이더가 중개 서버에 위치 정보를 갱신하는 API 이다.
상품을 픽업하고 배송을 완료하기까지, 라이더가 소지한 기기는 지속적으로 중개 서버의 위 API를 통해 위치 정보를 송신할 것이다.
이 때 처음으로 위치 정보를 보내는 API와 그 이후 정보를 갱신하는 API의 구분을 두지 않기 위해 위와 같은 프로세스를 거친다.

 

---

최종적으로 유저 플로우와 서비스 아키텍처를 완성했다.

유저 플로우 차트

서비스 아키텍처