[맞춤 제작 케이크 중개 서비스] 업체 도메인 도출 과정
서론
맞춤 제작 케이크 중개를 위해서는 고객을 위한 기능, 업체를 위한 기능, 관리자를 위한 기능 모두가 필요하다.
업체와 관련된 모든 로직을 담당하며 업체 도메인을 도출하는 과정에서 했던 생각들을 정리해보고자 한다.
현재 서비스에서 회원가입/로그인 방식으로 카카오 로그인 방식만 지원을 하고 자사 회원가입은 없는 상태이다.
업체용 회원가입을 만들고 따로 관리하는 것이 베스트지만, 일단 주어진 상황에서 최대한 추후 확장성을 고려하여 설계하였다.
현 상황에서, 사용자가 업체가 되고 싶다면 아래와 같은 프로세스를 거쳐야한다.
- 카카오 회원가입/로그인
- 업체 신청
- 관리자가 업체 신청을 보고 승인
- 승인 후 업체로 활동
업체 신청을 통해서 사용자에게 받아야하는 정보를 정할 때, 아래 조건들을 고려하며 정하였다.
- 고객이 무분별하게 업체 신청을 할 수 없도록 신청 과정에서 업체임을 확인할 수 있어야 함.
- 케이크 관련 업체가 아닌 경우 업체 신청이 되지 않아야 함.
과정
각 조건 별로 고려한 점을 하나씩 살펴보자.
1. 고객이 무분별하게 업체 신청을 할 수 없도록 신청 과정에서 업체임을 확인할 수 있어야 함
고객이 무분별하게 업체 신청을 할 수 없도록 신청 과정에서 사업자 등록번호를 확인하도록 하였다. 이 때 신뢰성을 위해 사업자 등록증 사진을 함께 업로드 받도록 하였다. 그럼에도 조작 가능성이 있으니 사업자 등록 번호를 인증할 수 있으면 좋을 것 같아서 사업자 등록 번호 관련 외부 API 가 있는지 확인해보았다.
위와 같은 외부 API 를 사용하여 실제 등록되어 있는 사업자인지 확인할 수 있다.
2. 케이크 관련 업체가 아닌 경우 업체 신청이 되지 않아야 함
이는 사업자 등록 번호의 업종 코드를 통해 확인할 수 있다. 케이크와 관련된 업종은 보통 제과업, 휴게음식점업, 즉석판매제조업이 있다. 위에서 사업자 등록 번호를 받고 어플리케이션에서 검증 로직을 작성해주면 된다.
위의 과정들을 거치고 정리하여, 업체 신청 시 받아야할 정보를 아래와 같이 정하였다.
관리자가 업체를 관리하기 위해 필요한 정보
- 사업자 번호
- 사업자 등록증 이미지
- 사업자 이름
- 개업일
- 상호명
고객에게 노출해야하는 업체 정보 (업체가 수정 가능한 정보)
- 전화번호
- 주소
- 영업시간
- 업체에 대한 설명
- 업체 사진
위 정보들을 테이블에 어떻게 저장해야할까?
구분할 수 있어야하는 정보를 논리적으로 나누어보면 업체 신청 내역, 승인 여부, 승인된 업체를 구분할 수 있어야한다.
2가지 방법을 생각하였다.
첫번째는, 업체 신청 내역과 업체를 하나로 관리하고 승인 여부는 컬럼으로 관리하는 것이다.
두번째는, 업체 신청 내역과 업체 테이블을 분리하여 관리하는 방식이다 . 각각의 장단점을 한번 살펴보자.
업체 신청 내역과 승인된 업체를 하나의 테이블로 관리하고 승인 여부는 컬럼으로 관리
- "승인 여부" 컬럼에 승인, 대기, 거절 상태를 두는 방식으로 승인 여부를 관리한다. 이 승인 여부 컬럼이 승인이면 승인된 업체이고 아니면 업체 신청 내역인 것이다.
- 장점
- 하나의 테이블에서 모두 관리할 수 있다.
- 중복 저장되는 데이터가 없다.
- 단점
- 하나의 테이블이 하나의 데이터를 담고있지 않게 된다. 승인 업체에 대한 정보와, 업체 신청 내역에 대한 정보를 함께 가지게 된다.
- 이로 인해, 변경에 취약하게 된다. 승인 업체와 업체 신청 내역은 다른 종류의 정보인데 업체 신청에 대한 정책이 변경되어도 승인 업체 데이터가 영향을 받게 된다.
- 승인 업체 데이터를 조회할 때마다 승인 여부를 확인해줘야한다.
- 하나의 테이블이 하나의 데이터를 담고있지 않게 된다. 승인 업체에 대한 정보와, 업체 신청 내역에 대한 정보를 함께 가지게 된다.
업체 신청 내역과 승인 업체 테이블을 분리하여 관리하는 방식
- 장점
- 업체 신청에 대한 정보를 분리하기에 업체 신청 정책이 변해도 업체 신청 내역 테이블만 변경하면 된다. 업체 테이블은 영향받지 않는다.
- 승인 업체 데이터를 조회할 때 그냥 업체 테이블에서 바로 조회하면 된다. 업체 테이블에 있는 데이터는 다 승인된 것들이기 때문이다.
- 단점
- 업체 테이블과 업체 신청 테이블에 중복 저장되는 정보가 생긴다.
- 업체 신청 시 입력되는 고객에게 노출해야하는 업체 정보 (업체가 수정 가능한 정보) 는 업체 신청 내역, 업체 테이블 모두가 가져야 하는 컬럼이다.
- 업체 테이블과 업체 신청 테이블에 중복 저장되는 정보가 생긴다.
결론
업체 신청 내역과 승인 업체 테이블을 분리하여 관리하였다.
서비스를 운영하는 입장에서는 업체 신청 내역을 관리해야한다. 예를 들어보자면, 고객 입장에서 업체 신청을 했는데 승인이 안되어서 여러 번 신청을 하게될 수 있다. 이 때, 신청 내역이 있어야 어떤 식으로 업체 신청을 했는지, 왜 승인이 되지 않았는지 등을 관리할 수 있다. 그리고 이를 바탕으로 추후 새로운 정책을 만들 수도 있다. ex) 5번 이상 거절당했을 시 일주일 간 재신청 불가
업체 신청 내역과 승인된 업체를 하나의 테이블로 관리하고 승인 여부는 컬럼으로 관리하여도 업체 신청 내역을 관리할 수는 있다. 다만, 업체 신청이 승인되면 그 데이터를 승인 업체 데이터로 직접 활용하게된다. 그러면, 업체가 자신의 정보를 수정한 후부터는 업체 신청이 승인되었을 그 시점의 데이터는 다시는 조회할 수가 없게 된다.
승인 업체 테이블이 업체 신청 내역과 겹치는 컬럼이 많다. 승인 업체 테이블이 아예 업체 신청 내역 테이블을 참조하게 할 수도 있지만, 그렇게 하면 업체가 정보를 수정 시 업체 신청 내역 테이블이 변하게 된다. 업체 신청 내역은 신청 그 시점에서 데이터가 변하면 안된다. 그러므로 컬럼은 겹치더라도, 업체가 수정할 수 있는 필드들은 업체가 가지도록 하였다. 그렇기에 수정할 수 있는 정보(고객에게 노출해야하는 정보)들은 컬럼이 중복되는데, 이는 컬럼 명은 겹치지만 사실 논리적으로는 다른 데이터이므로 상관없다고 생각한다.