전체방문자

508,219

today 53
yesterday 892
본문 바로가기

FrameWork/Spring JPA

Spring JPA - JPA를 이용해 Commerce App 만들기 - 2 (설계 : 요구사항 분석, 도메인모델, 엔티티 설계)

Spring Boot - JPA를 이용해 Commerce App 만들기 - 2

이 포스팅은 김영한님의 실전! 스프링 부트와 JPA활용 1을 참고하여 작성되었습니다.

 

 

이번 포스팅에서는 우리가 만들 Commerce App의 요구사항 분석을 진행하고 이어 설계를 해보도록 하겠습니다.

 

 

 

요구사항 분석

우리가 만들어볼 App은 간단한 쇼핑몰입니다. 각 기능별 요구사항을 알아보도록 하겠습니다.

 

1. 회원

  • 회원 등록
  • 회원 조회

 

 

2. 상품

  • 상품 등록
  • 상품 수정
  • 상품 조회

* 상품은 재고관리가 필요합니다.

* 상품 종류에는 도서, 음반, 영화가 있습니다.

* 상품을 카테고리로 구분할 수 있습니다.

* 상품 주문시 배송 정보를 입력합니다.

 

 

3. 주문

  • 상품 주문
  • 상품 주문 취소
  • 주문 내역 조회

 

 

 

 

 

 

도메인 모델

다음으로 해야할 일은, 요구사항을 토대로 도메인 모델을 도출하는 것입니다.

 

 

큰 그림을 먼저 본 뒤, 각각의 부분의 테이블 관계설정의 이유에 대해 설명드리는 것이 이해가 쉬울것 같아 설계 결과를 먼저 보여드립니다.

 

 

1. 회원과 주문

회원은 여러번의 주문이 가능하기 때문에, 1:N관계를 가집니다.

 

 

2. 주문과 배송

각각의 주문에는 배송에 필요한 정보들이 필요하기 때문에, 주문과 배송은 1:1관계를 가집니다.

 

 

3. 주문과 상품

주문과 상품은 약간은 생각이 필요합니다. 먼저, 각 주문은 여러개의 상품을 포함할 수 있고, 또 각 상품역시 여러 주문에 포함될수 있습니다. 때문에 주문과 상품의 관계는 N:N입니다.

 

하지만 DB에서는 N:N 관계를 표현할 수 없기 때문에, 이들을 1:N , N:1 관계로 풀어서 표현해야 합니다. 추가적으로 이들 관계를 표현하기 위해 생성된 주문상품 테이블에는 상품수량정보가 추가적으로 담깁니다. 상품수량의 경우, 주문테이블과 상품테이블 어느쪽에도 속할수 없기 때문입니다.

 

 

4. 카테고리와 상품

카테고리는 여러 상품에 등록될 수있으며, 상품 역시 여러 카테고리를 포함할 수 있기 때문에, N:N관계입니다.

 

 

5. 상품과 도서, 음반, 영화

여러 종류의 상품이 존재하는데 이들은, 상품을 상속받도록 했습니다.

 

 

 

 

 

 

엔티티 설계

이어서, 도출해낸 도메인 모델을 토대로하여, 엔티티를 설계해보겠습니다. 마찬가지로 먼저 완성된 설계를 보고, 각각의 엔티티를 살펴보도록 하겠습니다.

 

  • 화살표선은 단방향 연관관계를 나타냅니다.
  • 실선은 양방향 연관관계를 나타냅니다.
  • 안이 비어있는 화살표선은 상속 관계를나타냅니다.
  • 빨간색 테두리는 연관관계를 나타내는 필드입니다.

 

 

1. 엔티티의 필드

우선은 각각의 엔티티에 포함된 필드들에 대해 알아보고, 이어 각엔티티들의 연관관계와 그 이유를 알아보도록 하겠습니다.

 

1.1 Member

id : db의 식별자로 사용됩니다.

name: 회원명을 나타냅니다.

address: 주소지를 나타냅니다. (Adress라는 별도의 밸류타입이 사용됩니다.)

 

1.2 Order

id: db의 식별자입니다.

*orderer: 주문자를 나타냅니다.

*orderItemList: 주문한 상품의 리스트를 나타냅니다.

*delivery: 배송정보를 나타냅니다.

orderDate: 주문한 시간을 나타냅니다.

orderStatus: 주문 상태를 나타냅니다. (OrderStatus라는 별도의 밸류타입이 사용됩니다.)

totalAmount: 각 item에 대한 주문 수량 * 가격의 모든 합을 나타냅니다.(Money라는 밸류타입이 사용됩니다.)

 

1.3 Delivery

id: ..

address: 배송지 (Address 밸류 타입이 사용됩니다.)

deliveryStatus: 배송상태 (DeliveryStatus 밸류 타입이 사용됩니다.)

 

1.4 OrderItem

id: ..

item: 주문한 상품

order: orderItem이 속한 주문

orderQuantity: 각 Item 주문 수량

orderItemAmount: item의 주문수량에 따른 총액

 

1.5 Item

id: ..

name: 상품명

price: 상품의 가격

stockQuantity: 상품의 재고량

categoryList: item이 속한 카테고리 리스트

 

1.6 Category

id: ..

name: 카테고리명

 

 

 

2. 엔티티 연관관계

2.1 Member와 Order

Member와 Order간의 관계는 주문에서 회원을 참조하는 단방향 연관관계 입니다. Member가 주문을 하기 때문에, Member에서 Order를 참조해야할 것 같지만, 그렇지 않습니다. 이유는 다음과 같습니다.

  • Order는 Member에 포함된 필드가 아닌, 별도의 엔티티입니다. 따라서, 각각의 Order에서 주문자를 찾기위해 Member를 참조하면 됩니다.
  • Member가 주문한 Order 목록을 가져올 때에도, Order 입장에서 Member의 식별자를 조건으로하여 검색을 하면 됩니다.

 

 

 

2.2 Order와 Delivery

Order에서 Delivery로의 단방향 연관관계를 맺습니다.

  • 주문정보를 조회할때, 배송정보가 필요하기 때문입니다.
  • 배송정보를 조회하고 조회한 배송정보에서 주문정보를 알아낼 필요가 없습니다.

 

 

 

2.3 Order와 OrderItem과 Item

Order에서 OrderItem을 참조하는 단방향 연관관계이며, OrderItem에서 Item을 참조하는 단방향 연관관계 입니다.

  • 주문정보를 조회했을 때, 각각의 주문한 상품에대한 정보를 조회합니다.
  • 반대로 주문정보에 포함된 각 주문상품을 먼저 조회한뒤, 주문상품이 포함된 주문을 조회할 일이 없습니다.

 

 

 

2.4 Item과 Category

Item에서 Category를 참조하는 단방향 연관관계입니다.

  • 주문정보에 포함된 상품의 카테고리를 조회하는 경우가 존재합니다.
  • *상품카탈로그에서, 카테고리별 상품목록을 받아오는 경우, item 테이블에서, 카테고리를 조건으로하여 검색하면 되기 때문에, Category에서 Item에 대한 연관관계를 가질 필요가 없습니다.