본문 바로가기

공부/ERD10

실전프로젝트 - ERD 초안 2 오늘 AM 09:30 ~ PM 02:00 까지 API설계에 대해서 프론트와 상의하여 조정을 하였고, 이후 PM 03:00 ~ PM 05:00 까지 조정한 API설계를 바탕으로 ERD 테이블을 수정하였습니다. 아래는 주말에 임의로 만들어 본 ERD 설계인데, 백엔드 팀원들과 의논을 하면서 전체적인 틀을 수정하여서 위와 같은 설계를 수정하였습니다. 크게 수정된 부분은 1. 유저평가 -> 유저 테이블에 병합 2. Bag테이블 추가 -> 유저가 등록할 수 있는 수량을 6개로 제한을 할 때 -> 일일이 유저의 ItemList.size()를 통해서 세는 것은 부담이 되기 때문에 cnt값으로 저장할 Bag 테이블을 추가 3. like는 post의 userId와 다르기 때문에, User테이블과 비-식별관계 (UserR.. 2022. 4. 25.
실전프로젝트 - ERD 초안 1 파란친구 : 객체참조(OneToMany)을 통해서, 연결할 친구들입니다. 빨간친구 : Repository에서 FinBy로 조회하는 친구들 -> 객체참조의 강한 의존성으로 부터 끊기 위한 것 어디든 탐색이 가능해짐 -> ORM / DB 매핑 - > 어디까지.... LAZY로딩이 발생할 수 있음 마음에 걸리는 부분) 1. 유저 = 가게같은 느낌 물물교환의 특성상 유저 = 가게라는 점에서 게시물 & 거래내역 & 등록제품을 객채참조를 끊는 것이 맞는 것 인지에 대한 의문이 생깁니다. -> 유저가 삭제가 되면, 등록 제품과 게시글 등이 동시에 삭제되야 하지 않는가? -> 유저가 삭제될때 -> userService에서 각각의 Repository를 FindByUser라는 조건으로 순서대로 삭제해야 되는 것인가? 2... 2022. 4. 25.
우아한 객체지향 강의 메모 - 05 https://youtu.be/dJ5C4qRqAgA?t=3859 객체 참조의 문제점 : 모든것을 참조 -> 다 쫒아가고 싶은 욕망 영구적인 결합체 -> 객체 참조 끊기 오더를 알면 -> 샵으로 찾아 갈 수 있어 방법 -> 객체 참조 (물리적인 강도 - 결압도가 굉장히 높은 방법) 약한 결합도 -> Repository를 통한 탐색 ShopId를 통한 탐색 Repository에 대한 인터페이스 -> 연관관계를 구현할 수 있는 뭐를 찾아! 파라미터를 -> 이 객체를 찾을 수 있도록 만듦 조회쪽이 깨지면서 깨짐 실제로 구현을 하게되면 -> 사용자에게 보여주기위한 연관관계를 덕지덕지 붙게됨 -> 비지니스 로직 어떤 객체들은 묶고, 결합도가 높은 친구들 굳이 필요 x 구분해서 해결해야 됨 -> 도메인에서 어떤 개념.. 2022. 4. 24.
우아한 객체지향 강의 메모 - 04 https://youtu.be/dJ5C4qRqAgA?t=2808 의존성 (디펜더시) - 펜으로 메모 그려보았을 때 이상한게 잇으면 -> 이상한 것 일단 짜고, 개선을 하다보면 원하는 방향으로감 -> 일단 의존성 관점에서 설계 페키지를 이름을 부여하고, 어느 클래스를 넣어야 하는지 그림 객체 이코드의 패키지 구조와 서비스 클래스 도메인 클래스 레이어 -> 개념 레이어를 어떻게 구현할거야? -> 패키지 패키지 안에 나눠둠 객체사이 -> 사이클이 돎 주문이 가게가 주문중인지, 오더와 샵 의존관계 (메시지) 관계가 강하기 때문에 연관관계 옵션그룹 오더옵션을 가져옴 양방향 연관관계가 됨 오더옵션을 고치고 싶을 때, 다른곳도 고쳐야되 결국 양쪽의 패키지를 고쳐야 됨 (의존성의 방향이 잘못) 샵 - 오더옥션 패키지의.. 2022. 4. 24.
우아한 객체지향 강의 메모 - 03 이유가 있어야함 연관관계 : 탐색가능성(navigability) 오더라는 -> 어떤 방식이든 찾아갈 수 있어 이객체를 알면 이겍체를 찾아갈 수 있 두 객체 사이에 협력이 필요하고 두 체의 관계가 영구적으로 필요 일반적으로 연관관계 구현 -> 객체 참조를 사용 코드가 나누고 분류하는 것 주문하기 협력 어떤 객체가 주문하기 메시지 를 받는 다는 것은 -> 그 객체의 Public 메소드로 구현이 된다. 메세지를 결정 -> 메소드를 만듦 2가지 로직 -> 주문이 올바른지 검증 -> 주문의 상태를 바꾼는 로직 order라는 객체가 플레이스를 받음 그러고나서 오더라는 각체가 샵과 오더라는 메시지를 보낼 수 있어야 됨 -> 영업중인지 검증 -> 최대 주문금액보다 많은지 검증 -> 항목들의 중요한 내용들을 비교해 ->.. 2022. 4. 23.
우아한 객체지향 강의 메모 - 02 https://youtu.be/dJ5C4qRqAgA?t=1338 6개의 항목을 체크를 확인 주문이 전송 가게가 영업여부를 확인 실제 주문금액이 최소 주문금액 이상인지 확 2.메뉴의 이름과 주문항목의 이름을 비교 주문항목쪽으로 검증을 해보라고 주문을 함 같은지를 비교해! -> 메시지 보내기 메뉴는 옵션그룹쪽에 메뉴와 주문항목이 같은지 체크, 같으면 -> 주문옵션그룹이랑 옵션그룹이랑 같은지 판단해! 옵션그룹은 -> 이름을 비교 이번엔 너가 주문데이터 옵션이랑 이름이 같은지를 확인해봐 -> 다 통과가 되면 주문이 완료가 된 것 e커머스 플로워 -> 전체적인 흐름 어떤식으로 주고받는지 개발자 : 시간 / 변화무쌍한 과정을 정적인 관계로 담아야 됨 (움직이지 않은 것) 관계 -> 의존성 정적인 부분으로 이어주고 .. 2022. 4. 23.