좀 더 발전한 '캠핏'의 Flow Chart
아래의 글을 2주간 공부한 내용을 바탕으로 보완하는 글입니다.
https://brunch.co.kr/@hyunn2/27
2주 전 예상한 캠핏의 예약 플로우 차트
캠핏의 사용자 플로우 차트 (Flow Chart)
회원가입 후 직접 검색을 통해 예약하는 과정
전체 사용자 플로우 (직접 제작 @hyunn2)
위의 전체 사용자 플로우 확대 (직접 제작 @hyunn2)캠핏의 클라이언트, 서버, DB 구조 추측하기
직접 제작 @hyunn2플로우 중 클라이언트, 서버, DB 간 상호작용이 일어날 것이라고 추측되는 단계를 뽑아서 간단하게 표현해보았다.
[로그인]
Server: DB에 회원 정보 요청
DB: 회원 정보 제공
[캠핑장 검색]
Server: DB에 제휴 및 협업 중인 모든 캠핑장 정보 요청
DB: 전체 캠핑장 정보 제공
[A캠핑장 선택], [A캠핑장 예약 가능 날짜 검색]
Server: DB에 A캠핑장 정보 요청
DB: A캠핑장 정보 제공
[예약]
Client: 인원 및 차량 정보 제공
Server: Client에 인원 및 차량 정보 요청/DB에 회원 기본 정보 요청
DB: 회원 기본 정보 제공
지금 다시 만들어 보는 캠핏의 예약 플로우 차트
클릭하여 확대 뭔가 발전한 것 같기도 하고... 아닌 것 같기도 하고.... 일단 유저와 클라이언트의 구분을 전혀 못하고 있었다는 점이 새삼 민망하다. 사실 클라이언트가 프론트엔드 개발자라는 걸 완벽하게 이해한 건 오늘의 토론(이라 쓰고 역할극이라 읽는) 덕분이라고 생각한다.
플로우가 애매해 생략했지만 로그인 과정에서 전달한 정보가 DB에 없어 재입력을 요청하는 것처럼, 모든 입력 과정에서 DB의 정보와 일치하지 않는 내용이 입력된다면 서버가 클라이언트에게 재입력을 요청할 것이다.
추가적으로 이전 글의 API를 생각해 본다면 회원가입 과정에서 API를 적용할 수 있을 것이고, 로그인 과정에서도 적용할 수 있을 것이다.
#PM #프로덕트 매니저 #IT #기획 #UX #UI #CX
