지금 현재 배달의민족 풀스택으로 만들고있는데
매번 고민이 되는게 그냥 USER랑 어드민은
Role Enum클래스 만들어서 관리하면 되는데
가게 사장님은 Role로 관리하기 약간 애매하단 말이지
가게 사장님이 회원가입 할때 필요한 데이터랑
일반 사용자가 회원가입 할때 사용하는 특성이 너무 다르고 물론 테이블 만들어서 FK로 해도 되지만
설계상 분리하는게 맞는것같아 또 분리하면
로그인 로직 회원가입 로직이 중복되는 문제가 발생한단 말야 이거를 LoginService로 따로 만들어서 해결했는데
더 좋은 해결방법이 있을까?? 매번 고민하는데
권한이랑 가게 사장님 혹은 쇼핑몰에서 브랜드는 Role보다는 엔티티를 분리하는게 맞는것같은데 너희들 생각은 어때?
- dc official App
회원 데이터 자체는 하나로 통일해야지 거기서 가게 사장이랑 일반 회원의 세부 데이터는 나눠서 관리하는게 좋을거고 그 외엔 뭔 말 하는지 횡설수설이 너무 심해서 이해가 안됨 Role Enum이랑 Entity랑 반대되는 개념이 아닌데 왜 양립할 수 없다고 생각하는지도
내 생각은 일반 회원이랑 사장님이랑 아이디, 비밀번호를 제외하면 모든 데이터가 전부 다르더라고 예를들어 사장님은 개인 사업자 번호부터 시작해서 대표이름 등등 데이터 특성 자체가 다른느낌이라 consumer 테이블을 만들어서 user에서 fk로 갖고있을까도 생각했는데 아이디 비밀번호를 제외하면 너무 데이터 특성이 다른데 그래야하나 걍 서비스를 분리하는게 맞지않아 생각했는데 별로임?? - dc App
인증이 조스로 보이십니까?
인증을 다단계로 구성할거면 테이블 분리해도 되긴 함 예를 들어 니 인증 시스템이 외부 인증 시스템이랑 연계할수도 있는 것처럼 근데 내부 시스템에서 왜 그런짓을..?
일단 DB에 널이 들어가는게 싫어 사장 데이터를 Owner테이블로 만들어서 User 테이블에 OwnerId를 관리해도 되지만 널이 들어가는게 너무 싫었어 - dc App
다단계로 안하면 니 말대로 중복로직 발생인데 사고가 이쪽으로 돌아간다면 개발자 접길 추천함 인증 중복로직이라니 상상만 해도 끔찍하네
1대1관계로 테이블 분리해
그리고 회원 계정과 사장이 꼭 1대1 관계라는 보장도 없음 가게 여러개 할 수도 있고 그때마다 사장으로서의 정보가 달라질수도 있는거라
일단 오키 중복로직이 너무 ㅈ같아서 코그 갈아엎어야겠네 - dc App
굳이 한 테이블로 쓰고싶으면 인증에 쓰이는 정보 외에는 전부 다 비정규 데이터로 관리하는거도 방법임
진짜 개병신짓하는거였구나 - dc App
풀스택 왜 하는지 모르겠음 백엔드만 설계해도 니 수준에서 절대로 제대로 못만듬
풀스택을 하는게 아니라 취업용 토이프로젝트 만드는데 프론트가 없으면 허전해서... 뷰 공부해서 하는중 ㅇㅅㅇ - dc App
tag: 흔한-허접의-착각
배민 전체 시스템 설계할 생각 하지 말고, 그 중에 일부만 제대로 설계하려고 해봐 그것만으로도 힘들거야
만약에말야 아주 만약에 대충 머 가게 대충 있고 머 대충 주문좀 하고 머 이정도 수준 생각한거면 진짜 다시 생각해봐
나름 범위를 줄인게 딱 고객, 사장님, 카테고리, 상품, 리뷰, 주문으로 바운더리를 좁혀놨음 - dc App
그게 어떤 경쟁력이 있을지도 한번 생각해봐 기술적으로 어떤걸 어필할 수 있어?
줄여도 제일 필요 없는거만 모아서 줄여놨네
뭔가를 처음 시작할때, 이걸로 내가 뭘 얻고싶은지를 명확하게 하고 가야해 안그럼 시간낭비임
진짜 핵심 기능으로 바운더리를 좁히고 기술적으로는 내가 CS를 고민한 문제를 녹이려했음 - dc App
CS 고민한거 녹이기에 너무나 큰 바운더리임
비즈니스적으로 완성된 무언가를 하려고 하지마 너는 기획자가 아니야 서비스 클론코딩 제발 하지마 그거 왜 하는거임?
인증이고 뭐고 다 넣지 마 인증 넣을거면 인증 시스템이나 제대로 구현해보던지 기술적인 고민만 할거면 딱 기술에만 집중해 근데 맥락 없이 기술만 이야기하기 좀 애매하니까 차용하는게 실서비스 개념일 뿐이야
새로 글 쓴거봐줘 - dc App
무슨 소린지는 이해했는데 음.. 이 기술적 고민이라는게 가령 쿠폰서비스만해도 되게 깊이생각하면 깊어지잖아 근데 이 쿠폰서비스를 만들려면 상품도 필요하고 상품이 필요하면 카테고리도 필요하고 그러다보면 실서비스를 모델링하는게 편하잖아.. - dc App
전혀 그렇지 않음 쿠폰 발급 서비스가 상품에 의존한다는건 대체 누구한테 들은거임?
들은건 아니고 현실에서는 상품이 있어야 쿠폰이 의미가 있으니까 당연히 둥다 구현하려했지 - dc App
매우 잘못 생각한것임
근데 저사람이 좁혀놓은 범위가 딱 없어선안되는 핵심파츠인거아님? 필요없다는게 어떤면에서 필요없다는건지 궁금한데
웃스음 제대로 이해했는지 검증해보자 설명 고고
개발자는 풀고 싶은 문제를 정의하고 여기서 좋은 고민으로 녹여야해, 예를 포폴 주제가 예약시스템이면 문제를 명확히 정의했잖아 그리고 이런 주제에서 좋은 고민을 하는게 좋은 포폴이라는거임 하나를 만들더라도 대충 단순히 만드는게 아니라 깊게 만드는거지 가령 자료구조로 비유를 들면 큐를 규현한다고 해보자 왠만한 자료구조 책에거 큐의 코드를 제공해주잖아? 큐를 공부할 때 단순히 저 책에 있는 내용만 이해하는게 이런 질문을 해볼수 있어 1. 멀티스레딩에서 큐가 잘 작동할까? 이 문제를 해결하면 다음 문제가 나오겠지 2. 락을 걸어서 해결했는데 어떻게 하면 속도가 더 빨라질까? 3. 큐에 데이터를 백만개 이상 넣으면 어떻게될까? 등등 수 많은 고민을 해볼 수 있고, - dc App
좁은 주제로 자료구조에서도 깊이있는 고민을 할수있는데 내 주제는 좋은 고민을 하기에는 쓸모없는 기능이 너무 많았어 위 예처럼 단순히 쿠폰시스템에서 발생할 수 있는 문제를 대용랑 동시성을 고려해도 엄청~ 어렵고 충분한데 ㅈ나 의미가 없는 CRUD가 너무 많았어 - dc App
완벽하게 설명해줬다 핵심은 하나를 만들더라도 제대로 만들라는 거야 - dc App