참고
어플리케이션 구현 준비
NOTE
•
로그인, 권한 관리 X
•
파라미터 검증 및 예외 처리 X
•
상품은 도서만 사용
•
카테고리는 사용 X
•
배송 정보는 사용 X
아키텍쳐
NOTE
•
계층형 구조
◦
Controller, web : 웹 계층
◦
Service : 비즈니스 로직, 트랜잭션 처리
◦
Repository : JPA를 직접 사용하는 계층, Entity Manager 사용
◦
Domain : Entity가 모여있는 계층, 모든 계층에서 사용된다.
•
개발 순서
◦
Service → Repository → testCase작성 및 검증 → 웹 계층 적용
요구사항 분석
기능 목록
NOTE
•
회원 기능
◦
회원 등록
◦
회원 조회
•
상품 기능
◦
상품 등록
◦
상품 수정
◦
상품 조회
•
주문 기능
◦
상품 주문
◦
주문 내역 조회
◦
주문 취소
•
기타 요구사항
◦
상품은 재고관리가 필요하다.
◦
상품의 종료는 도서, 음반, 영화가 있다.
◦
상품을 카테고리로 구분할 수 있다.
도메인 모델과 테이블 설계
NOTE
도메인 모델
•
회원, 주문, 상품의 관계
◦
회원은 여러 상품을 주문할 수 있고, 한 번 주문할 때 여러 상품을 선택할 수 있다. 그러므로 주문과 상품은 다대다 관계이다.
◦
하지만 이런 다대다 관계는 관계형 데이터베이스는 물론이고, entity에서도 거의 사용하지 않으므로, 주문상품이라는 entity를 추가해서 다대다 관계 → 일대다, 다대일 관계로 풀어냈다.
•
상품 분류
◦
상품은 도서, 음반, 영화로 구분되는데 상품이라는 공통 속성을 사용하므로 상속 구조로 표현한다.
회원 엔티티 분석
•
Member(회원)
◦
이름과 임베디드 타입인 주소, 주문 리스트를 가진다.
•
Order(주문)
◦
주문은 상품을 주문한 회원과 배송 정보, 주문 날짜, 주문 상태를 가지고 있다.
◦
주문 상태는 Enum을 사용함(ORDER, CANCEL)
•
OrderItem(주문 상품)
◦
주문한 상품 정보와 주문 금액, 주문 수량 정보를 가지고 있다.
•
Item(상품)
◦
이름, 가격, 재고수량을 가지고 있다.
◦
상품을 주문하면 재고 수량이 들어든다.
◦
상품의 종류로는 도서, 음반, 영화가 있는데 각각은 사용하는 속성이 조금씩 다르다.
•
Delivery
◦
주문 시 하나의 배송 정보를 생성한다.
◦
주문과 배송은 일대일 관계다.
•
Category(카테고리)
◦
상품과 다대다 관계를 맺는다.
◦
parent, child로 부모, 자식 카테고리를 연결한다.
•
Address(주소)
◦
값 타입(임베디드)으로 회원과 배송에서 사용한다.
[ 참고]
•
주문을 하기 떄문에, 회원이 주문 리스트를 가지는 것은 잘 설계한 것 같지만, 객체지향 관점에서 봤을 때 회원이 주문을 참조하지 않고, 주문이 회원을 참조 하는 것으로 충분하다.
⇒ 다대일 양방향의 연관관계를 이해하기 위해 사용했다고 생각하자.
회원 테이블 분석
•
Member 테이블
◦
회원 Entity의 Address 임베디드 타입 정보가 회원 테이블과 배송 테이블에 들어간다
•
ITEM 테이블
◦
앨범, 도서, 영화 타입을 통합해서 하나의 테이블로 DTYPE 컬럼을 통해 구분하도록 만들었다. (싱글 테이블 전략)
[ 참고]
•
데이터베이스 네이밍 방식은 회사마다 다르지만 보통은 대문자+_ 나 소문자+_로 지정해서 일관성 있게 사용한다.
•
현재 수업에서는 소문자+_ 방식을 사용함
연관관계 매핑 분석
NOTE
엔티티와 테이블 한눈에 보기
•
회원과 주문
◦
일대다, 다대일의 양방향 관계
◦
외래 키가 있는 주문을 연관관계의 주인으로 설정
•
주문상품과 주문
◦
다대일 양방향 관계
◦
주문 상품이 연관관계 주인
•
주문상품과 상품
◦
다대일 단방향 관계
•
주문과 배송
◦
일대일 양방향 관계
[ 참고]
•
외래 키가 있는 곳을 연관관계의 주인으로 정하자!
◦
연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지, 비즈니스 상 우위에 있다고 주인으로 정하면 안된다!
◦
그렇지 않으면 관리와 유지보수가 어렵고, 업데이트 쿼리가 발생하는 성능 문제도 있을 수 있다.