본문 바로가기
Back End/Spring

[Spring] 간단한 쇼핑몰 예제

by SolaKim 2023. 7. 23.

도메인 설계 

  • 회원 기능
    • 회원 등록
    • 회원 조회
  • 상품 기능
    • 상품 등록
    • 상품 수정
    • 상품 조회
  • 주문 기능
    • 상품 주문
    • 주문 내역 조회
    • 주문 취소
  • 기타 요구사항
    • 상품의 재고 관리
    • 상품 종류로는 도서, 음반, 영화 (카테고리)
    • 상품 주문시 배송 정보 입력

 

도메인 모델과 테이블 설계

회원, 주문, 상품의 관계 : 

  • 회원은 여러 상품 주문 가능 (주문 ↔️ 상품 다대다 관계)
  • 하지만 다대다 관계는 관계형 데이터베이스와 엔티티에서 거의 사용하지 않는다.
  • 위 그림처럼 주문 상품이라는 엔티티를 추가해서 일대다, 다대일 관계로 풀어낸다.

 

상품 분류 : 

  • 도서, 음반, 영화는 상품이라는 공통 속성을 사용하므로 상속 구조로 표현한다.

 

회원 엔티티 분석

 

회원(Member): 이름과 임베디드 타입인 주소(Address), 그리고 주문(orders) 리스트를 가진다.

주문(Order):

  • 한번 주문시 여러 상품을 주문할 수 있으므로 주문과 주문 상품(OrderItem)은 일대다 관계다.
  • 주문은 상품을 주문한 회원과 배송 정보, 주문 날짜, 주문 상태(status)를 가지고 있다. 
  • 주문 상태는 열거형 사용 (ORDER, CANCEL)

주문상품(OrderItem): 주문한 상품 정보와 주문금액(orderPrice), 주문수량(count) 정보를 가지고 있다.

상품(Item): 

  • 이름, 가격, 재고수량(stockQuantity)를 가지고 있다.
  • 상품을 주문하면 재고수량이 줄어든다.
  • 도서, 음반, 영화 각각 사용하는 속성이 조금씩 다르다.

배송(Delivery): 주문시 하나의 배송 정보를 생성한다. 주문과 배송은 일대일 관계다.

카테고리(Category): 상품과 다대다 관계를 맺는다. parent , child 로 부모, 자식 카테고리를 연결한다.

주소(Address): 값 타입(임베디드 타입)이다. 회원과 배송(Delivery)에서 사용한다.

 

회원 테이블 분석

 

연관관계 매핑 분석

회원과 주문: 일대다 , 다대일의 양방향 관계다. 따라서 연관관계의 주인을 정해야 하는데, 외래 키가 있는 주문을 연관관계의 주인으로 정하는 것이 좋다. 그러므로 Order.member 를 ORDERS.MEMBER_ID 외래 키와 매핑한다.

 

주문상품과 주문: 다대일 양방향 관계다. 외래 키가 주문상품에 있으므로 주문상품이 연관관계의 주인이다. 그러므로 OrderItem.order 를 ORDER_ITEM.ORDER_ID 외래 키와 매핑한다.

 

주문상품과 상품: 다대일 단방향 관계다. OrderItem.item 을 ORDER_ITEM.ITEM_ID 외래 키와 매핑한다.

 

주문과 배송: 일대일 양방향 관계다. Order.delivery 를 ORDERS.DELIVERY_ID 외래 키와 매핑한다.

 

카테고리와 상품: @ManyToMany 를 사용해서 매핑한다.(실무에서 @ManyToMany는 사용x)

 

참고: 외래 키가 있는 곳을 연관관계의 주인으로 정해라.
연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스상 우위에 있다고 주인으로 정하면 안된다.. 예를 들어서 자동차와 바퀴가 있으면, 일대다 관계에서 항상 다쪽에 외래 키가 있으므로 외래 키가 있는 바퀴를 연관관계의 주인으로 정하면 된다. 물론 자동차를 연관관계의 주인으로 정하는 것이 불가능 한 것은 아니지만, 자동차를 연관관계의 주인으로 정하면 자동차가 관리하지 않는 바퀴 테이블의 외래 키 값이 업데이트 되므로 관리와 유지보수가 어렵고, 추가적으로 별도의 업데이트 쿼리가 발생하는 성능 문제도 있다. 

 

 

엔티티 설계시 주의점

참고: 실무에서는 @ManyToMany 를 사용하지 말자
> @ManyToMany 는 편리한 것 같지만, 중간 테이블( CATEGORY_ITEM )에 컬럼을 추가할 수 없고, 세밀하게 쿼리를 실행하기 어렵기 때문에 실무에서 사용하기에는 한계가 있다. 중간 엔티티( CategoryItem 를 만들고 @ManyToOne , @OneToMany 로 매핑해서 사용하자. 정리하면 다대다 매핑을 일대다, 다대일 매핑으로 풀어내서 사용하자.

 

엔티티에는 가급적 Setter를 사용하지 말자

Setter가 모두 열려있다. 변경 포인트가 너무 많아서, 유지보수가 어렵다. 나중에 리펙토링으로 Setter 제거

 

모든 연관관계는 지연로딩으로 설정!

  • 즉시로딩( EAGER )은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다.
  • 실무에서 모든 연관관계는 지연로딩( LAZY )으로 설정해야 한다.
  • 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용한다.
  • @XToOne(OneToOne, ManyToOne) 관계는 기본이 즉시로딩이므로 직접 지연로딩으로 설정해야 한다.

 

컬렉션은 필드에서 초기화 하자.

  • 컬렉션은 필드에서 바로 초기화 하는 것이 안전하다.
  • null 문제에서 안전하다.
  • 하이버네이트는 엔티티를 영속화 할 때, 컬랙션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한다. 만약 getOrders() 처럼 임의의 메서드에서 컬력션을 잘못 생성하면 하이버네이트 내부 메커니즘에 문제가 발생할 수 있다. 따라서 필드레벨에서 생성하는 것이 가장 안전하고, 코드도 간결하다.

 

실제 애플리케이션 구현

애플리케이션 아키텍쳐

계층형 구조 사용

  • controller, web: 웹 계층
  • service: 비즈니스 로직, 트랜잭션 처리
  • repository: JPA를 직접 사용하는 계층, 엔티티 매니저 사용
  • domain: 엔티티가 모여 있는 계층, 모든 계층에서 사용

패키지 구조

  • jpabook.jpashop
    • domain
    • exception
    • repository
    • service
    • web

 

개발순서 : 서비스 ➡️ 리포지토리 계층 개발 ➡️ 테스트 케이스 작성/검증 ➡️ 웹계층 적용

 

 

회원 도메인 개발

MemberRepository

  • 기술 설명
    • @Repository : 스프링 빈으로 등록, JPA 예외를 스프링 기반 예외로 예외 변환
    • @PersistenceContext : 엔티티 매니저(EntityManager) 주입
    • @PersistenceUnit : 엔티티 매니저 팩토리 주입
  • 기능 설명
    • save()
    • findOne()
    • findAll()
    • findByName()

 

 

MemberSerivce

  • 기술 설명
    • @Service
    • @Transactional : 트랜잭션, 영속성 컨텍스트
      • readOnly=true : 데이터의 변경이 없는 읽기 전용 메서드에 사용, 영속성 컨텍스트를 플러시 하지 않으므로 약간의 성능 향상(읽기 전용에는 다 적용)
      • 데이터베이스 드라이버가 지원하면 DB에서 성능 향상
    • @Autowired
      • 생성자 Injection 많이 사용, 생성자가 하나면 생략 가능
  • 기능 설명
    • join()
    • findMembers()
    • findOne()

참고 : 스프링 필드 주입 대신에 생성자 주입을 사용하자

  • 생성자 주입 방식을 권장
  • 변경 불가능한 안전한 객체 생성 가능
  • 생성자가 하나면, @Autowired를 생략할 수 있다.
  • final 키워드를 추가하면 컴파일 시점에 memberRepository를 설정하지 않는 오류를 체크할 수 있다. (보통 기본 생성자를 추가할 때 발견)

 

 

테스트 케이스와 같은 경우는 아래 링크를 참고해서 작성해보자.

참고: 테스트 케이스 작성 고수 되는 마법: Given, When, Then
(http://martinfowler.com/bliki/GivenWhenThen.html)
> 이 방법이 필수는 아니지만 이 방법을 기본으로 해서 다양하게 응용하는 것을 권장한다.

 

 

 

상품 도메인 개발

상품 엔티티 코드에 비즈니스 로직 추가

Item

  • 비즈니스 로직 분석
    • addStock() 메서드는 파라미터로 넘어온 수만큼 재고를 늘린다. 이 메서드는 재고가 증가하거나 상품 주문을 취소해서 재고를 다시 늘려야 할 때 사용한다.
    • removeStock() 메서드는 파라미터로 넘어온 수 만큼 재고를 줄인다. 만약 재고가 부족하면 예외가 발생한다. 주로 상품을 주문할 때 사용한다.

 

ItemRepository

  • 기능설명
    • save()
      • id가 없으면 신규로 보고 persist() 실행
      • id가 있으면 이미 데이터베이스에 저장된 엔티티를 수정한다고 보고, merge()를 실행

 

 

 

주문 도메인 개발

Order

  • 기능 설명
    • 생성 메서드(createOrder()) : 주문 엔티티를 생성할 때 사용한다. 주문 회원, 배송 정보, 주문 상품의 정보를 받아서 실제 주문 엔티티를 생성한다.
    • 주문 취소(cancel()) : 주문 취소시 사용한다. 주문 상태를 취소로 변경하고 주문 상품에 주문 취소를 알린다. 만약 이미 배송을 완료한 상품이면 주문을 취소하지 못하도록 예외를 발생시킨다.
    • 전체 주문 가격 조회 : 주문 시 사용한 전체 주문 가격을 조회한다. 전체 주문 가격을 알려면 각각의 주문 상품 가격을 알아야한다. 로직을 보면 연관된 주문 상품들의 가격을 조회해서 더한 값을 반환한다. 

 

OrderItem

  • 기능 설명
    • 생성 메서드(createOrderItem()) : 주문 상품, 가격, 수량 정보를 사용해서 주문 상품 엔티티를 생성한다. 그리고 item.removeStock(count)를 호출해서 주문한 수량만큼 상품의 재고를 줄인다.
    • 주문취소(cancel()): getItem().addStock(count)를 호출해서 취소한 주문 수량 만큼 상품의 재고를 증가시킨다.
    • 주문 가격 조회(getTotalPrice()) : 주문 가격에 수량을 곱한 값을 반환한다.

 

OrderRepository

  • 주문 리포지토리에는 주문 엔티티를 저장하고 검색하는 기능이 있다.

 

OrderService

  • 주문 서비스는 주문 엔티티와 주문 상품 엔티티의 비즈니스 로직을 활용해서 주문, 주문 취소, 주문 내역 검색 기능을 제공한다.
  • 주문(order()) :  주문하는 회원 식별자, 상품 식별자, 주문 수량 정보를 받아서 실제 주문 엔티티를 생성한 후 저장한다.
  • 주문 취소(cancelOrder()): 주문 식별자를 받아서 주문 엔티티를 조회한 후 주문 엔티티에 주문 취소를 요청한다.
  • 주문 검색(findOrders()) : OrderSearch라는 검색 조건을 가진 객체로 주문 엔티티를 검색한다. 

 

참고: 주문 서비스의 주문과 주문 취소 메서드를 보면 비즈니스 로직 대부분이 엔티티에 있다. 서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할을 한다.

이처럼 엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 것을 도메인 모델 패턴(http://martinfowler.com/eaaCatalog/domainModel.html)이라 한다.
반대로 엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 것을 트랜잭션 스크립트 패턴(http://martinfowler.com/eaaCatalog/transactionScript.html)이라 한다.

 

 

 

변경 감지와 병합(merge)

 

준영속 엔티티?

영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다.

(여기서는 itemService.saveItem(book)에서 수정을 시도하는 Book 객체다. Book 객체는 이미 DB에 한번 저장되어서 식별자가 존재한다. 이렇게 임의로 만들어낸 엔티티도 기존 식별자를 가지고 있으면 준영속 엔티티로 볼 수 있다.)

 

준영속 엔티티를 수정하는 2가지 방법

  • 변경 감지 기능 사용
  • 병합(merge) 사용

 

변경 감지 기능 사용

@Transactional
void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티
	Item findItem = em.find(Item.class, itemParam.getId()); //같은 엔티티를 조회한다.
	findItem.setPrice(itemParam.getPrice()); //데이터를 수정한다.
}

영속성 컨텍스트에서 엔티티를 다시 조회한 후에 데이터를 수정하는 방법

트랜잭션 안에서 엔티티를 다시 조회, 변경할 값 선택 ➡️ 트랜잭션 커밋 시점에 변경 감지(Dirty Checking)이 동작해서 데이터베이스에 UPDATE SQL 실행

 

병합 사용

병합은 준영속 상태의 엔티티를 영속 상태로 변경할 때 사용하는 기능이다.

@Transactional
void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티
	Item mergeItem = em.merge(itemParam);
}

병합 : 기존에 있는 엔티티

병합 동작 방식

  1. merge()를 실행한다.
  2. 파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회한다.
    1. 만약 캐시에 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고, 1차 캐시에 저장한다.
  3. 조회한 영속 엔티티(mergeMember)에 member 엔티티의 값을 채워 넣는다.(member 엔티티의 모든 값을 mergeMember에 밀어 넣는다. 이때 mergeMember의 "회원 1"dlfksms dlfmadl "회원명변경"으로 바뀐다.
  4. 영속 상태인 mergeMember를 반환한다.

 

병합시 동작 방식을 간단히 정리 
1. 준영속 엔티티의 식별자 값으로 영속 엔티티를 조회한다. 
2. 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체한다.(병합한다.) 
3. 트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 데이터베이스에 UPDATE SQL이 실행 

주의: 변경 감지 기능을 사용하면 원하는 속성만 선택해서 변경할 수 있지만, 병합을 사용하면 모든 속성이 변경된다. 병합시 값이 없으면 null 로 업데이트 할 위험도 있다. (병합은 모든 필드를 교체한다.)

상품 리포지토리에선 save() 메서드를 유심히 봐야 하는데, 이 메서드 하나로 저장과 수정(병합)을 다 처리한다. 코드를 보면 식별자 값이 없으면 새로운 엔티티로 판단해서 persist()로 영속화하고 만약 식별자 값이 있으면 이미 한번 영속화 되었던 엔티티로 판단해서 merge() 로 수정(병합)한다. 결국 여기서의 저장 (save)이라는 의미는 신규 데이터를 저장하는 것뿐만 아니라 변경된 데이터의 저장이라는 의미도 포함한다. 이렇게 함으로써 이 메서드를 사용하는 클라이언트는 저장과 수정을 구분하지 않아도 되므로 클라이언트의 로직이 단순해진다.

여기서 사용하는 수정(병합)은 준영속 상태의 엔티티를 수정할 때 사용한다. 영속 상태의 엔티티는 변경 감지(dirty checking)기능이 동작해서 트랜잭션을 커밋할 때 자동으로 수정되므로 별도의 수정 메서드를 호 출할 필요가 없고 그런 메서드도 없다.

 

엔티티를 변경할 때는 항상 변경 감지를 사용해라

  • 컨트롤러에서 어설프게 엔티티를 생성하지 마라.
  • 트랜잭션이 있는 서비스 계층에 식별자( id )와 변경할 데이터를 명확하게 전달해라.(파라미터 or dto)
  • 트랜잭션이 있는 서비스 계층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경하라.
  • 트랜잭션 커밋 시점에 변경 감지가 실행된다.
@Controller
@RequiredArgsConstructor
public class ItemController {
    private final ItemService itemService;
    /**
    * 상품 수정, 권장 코드
    */
    @PostMapping(value = "/items/{itemId}/edit")
    public String updateItem(@PathVariable Long itemId, @ModelAttribute("form")
    BookForm form) {
        itemService.updateItem(itemId, form.getName(), form.getPrice(),
        form.getStockQuantity());
        return "redirect:/items";
    }
}

 

package jpabook.jpashop.service;
@Service
@RequiredArgsConstructor
public class ItemService {
    private final ItemRepository itemRepository;
    /**
    * 영속성 컨텍스트가 자동 변경
    */
    @Transactional
    public void updateItem(Long id, String name, int price, int stockQuantity)
    {
        Item item = itemRepository.findOne(id);
        item.setName(name);
        item.setPrice(price);
        item.setStockQuantity(stockQuantity);
    }
}

 

 

 

상품 주문 개발

상품 주문 컨트롤러

  • 주문 폼 이동
    • 메인 화면에서 상품 주문을 선택하면 /order를 GET 방식으로 호출
    • OrderController의 createForm() 메서드
    • 주문 화면에는 주문할 고객 정보와 상품 정보가 필요하므로 model 객체에 담아서 뷰에 넘겨줌
  • 주문 실행
    • 주문할 회원과 상품 그리고 수량을 선택해서 Submit버튼을 누르면 /order URL을 POST 방식으로 호출
    • 컨트롤러의 order() 메서드를 실행
    • 이 메서드는 고객 식별자(memberId), 주문할 상품 식별자(itemId), 수량(count) 정보를 받아서 주문 서비스에 주문을 요청
    • 주문이 끝나면 상품 주문 내역이 있는 /orders URL로 리다이렉트

 

 

 

주문 목록 검색, 취소



👇🏻 👀 👇🏻

 전체 코드 

 

🤩 공부한 내용과 이미지 출처 :

'Back End > Spring' 카테고리의 다른 글

[Spring] 웹 애플리케이션의 이해...  (0) 2023.08.01
[Spring] Spring MVC의 @ModelAttribute 어노테이션  (0) 2023.07.31
Spring - 빈 스코프  (0) 2023.07.17
Spring - 빈 생명주기 콜백  (0) 2023.07.16
Spring - 자동과 수동 주입의 올바른 운영 기준  (0) 2023.07.16

관련글

티스토리툴바