Persistence Layer

이전에 봤던 Persistence Layer 는 Data Access 에 집중한 레이어였습니다.

지금은 JPA 레포지토리를 사용해서 비즈니스 로직이 끼어들 틈이 사실상 없었지만 QueryDSL을 사용하거나 별도의 DAO 클래스들을 사용하면서 비즈니스 로직이 침투하게 작성하는 분들이 있습니다.

하지만 Persistence Layer 에서는 정말 데이터에 접근하는 역할만 가져가야지 비즈니스 로직 자체가 이 레이어에 침투하게 되면 우리가 수행해야하는 비즈니스 로직이 분산 됩니다.

그렇기 때문에 데이터에 대한 CRUD 작업에만 집중한 레이어로 인식을 하고 코드를 작성해야하며 테스트도 마찬가지로 인식에 맞춰서 진행을 하면 됩니다.

Business Layer

• Business Layer 는 비즈니스 로직을 구현하는 역할
  • 쉽게 말해서 우리가 구현해야하는 요구사항들을 구현하는 역할입니다.
• Persistance Layer 와의 상호작용(Data 를 읽고 쓰는 행위)을 통해 비즈니스 로직을 전개시킵니다.
  • 리포지토리에서 필요한 것들을 조회, 저장, 삭제 등을 하면서 로직을 진행합니다.
• 트랜잭션을 보장해야 합니다.
  • 로직을 전개하다가 문제가 생기면 예외가 발생하고 롤백을 해야합니다. 이런 롤백에 대한 트랜잭션을 보장해야 되기 때문에 작업 단위에 대한 원자성을 보장해주는 책임을 가지는 곳이 비즈니스 레이어입니다.

다시 Layered Architecture 그림을 봅시다.

Persistence Layer 같은 경우는 JpaRepository 를 상속 받은 Repository 를 test 함으로써 진행을 했었습니다.

스프링을 띄우니까 통합 테스트이긴 하지만 레이어만 똑 떼어서 테스트를 하기 때문에 단위 테스트 느낌이 난다고 했습니다.

이렇게 이야기를 한 이유는 Business Layer 는 Persistence Layer 를 통합한 두 레이어를 한번에 테스트하는 느낌으로 작성할 예정이기 때문입니다.

Service test는 Persistence Layer 를 배제하지 않고 Business Layer 를 테스트하면서 통합적으로 동작하는지 작성을 해볼 겁니다.

진짜 통합 테스트 같은 느낌이 나게 말이죠.

요구사항

디스플레이에 어떤 메뉴들이 나오는지 앞서 구현했던 API로 보여줬으니 주문을 만들어봅시다.

메뉴를 여러 개 선택해서 가격을 보고 주문하기를 누르면 주문이라는 엔티티가 생성이 되도록 구현해봅시다.