계층형 아키텍처 사용할 거임
controller, web : 웹계층
service : 핵심 비즈니스 로직, 트랜잭션 처리
repository : JPA를 직접사용하는 계층, 엔티티 매니저 사용
domain : 엔티티가 모여 있는 계층. 모든 계층에서 사용.
근데 여기서 컨트롤러가 직접 repository를 사용하기도 하도록 만든다고 한다.
아키텍쳐 딱딱하게 설계해서 간단한 조회같은 건데 무조건 service타게하는 것도 좀 그렇다고..
패키지 구조
exception은 예외 공통처리를 모아놓은 곳
개발순서
서비스, 리포지토리, 도메인 먼저 계발. 도메인인 이미 우리가 설계를 많이 하긴 함.
근데 추가적인 비즈니스 메소드가 도메인에 들어감(엔티티의 장점)
웹 환경을 제외한 핵심 비즈니스 계층을 먼저 개발하고,
테스트 케이스를 작성해서 검증을 한 다음에,
이렇게 다 된 상태에서 마지막에 웹환경, 컨트롤러에 들어갈 거임.
웹환경 전까지
회원 도메인 개발
회원리포지토리 개발
회원 서비스 개발
회원 기능 테스트
상품 도메인 개발
상품 엔티티 개발
상품 리포지토리 개발
상품 서비스 개발
주문 도메인 개발
주문, 주문 상품 엔티티 개발
주문 리포지토리 개발
주문 서비스 개발
주문 기능 테스트
주문 검색 기능 개발
이렇게 할 거임.
각각의 도메인마다 리포지토리, 서비스를 만드는 듯.
'스프링데이터 + JPA > 웹 애플리케이션 개발' 카테고리의 다른 글
13. 회원 서비스 (0) | 2023.11.06 |
---|---|
12. 회원 리포지토리 (0) | 2023.11.06 |
10. 구현 요구사항 (0) | 2023.11.05 |
9. 엔티티 개발 주의점 (0) | 2023.11.05 |
8. 엔티티 개발 2 (0) | 2023.11.05 |