[ Spring Boot ] API

API를 만들기 위해 총 3개의 클래스가 필요

• Request 데이터를 받을 DTO
• API 요청을 받을 Controller
• 트랜잭션, 도메인 기능 간의 순서를 보장하는 Service

✅ 여기서 많은 오해 → Service에서 비즈니스 로직을 처리해야 한다는 것
But, 전혀 그렇지 않음
✅ Service는 트랜잭션, 도메인 간 순서 보장의 역할만 함

• Web Layer
  • 흔히 사용하는 컨트롤러(@Controller)와 JSP/Freemarker 등의 뷰 템플릿 영역
  • 이외에도 필터(@Filter), 인터셉터, 컨트롤러 어드바이스(@ControllerAdvice)등 외부 요청과 응답에 대한 전반적인 영역
• Service Layer
  • @Service에 사용되는 서비스 영역
  • 일반적으로 Controller와 Dao 중간 영역에서 사용됨
  • @Transactionaldl 사용되어야 하는 영역이기도 함
• Repository Layer
  • Database와 같이 데이터 저장소에 접근하는 영역
  • DAO(Data Access Object) 영역
• Dtos
  • Dto(Data Transfer Object)는 계층 간에 데이터 교환을 위한 객체를 이야기하면 Dtos는 이들의 영역
  • 에를 들어, 뷰 템플릿 엔진에서 사용될 객체나 Repository Layer에서 결과로 넘겨준 객체 등이 이들을 이야기함
• Domain Model
  • 도메인이라 불리는 개발 대상을 모든 사람이 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화시킨 것을 도메인 모델이라고 함
  • 예를 들어, 택시 앱이라고 하면 배차, 탑승, 요금등이 모두 도메인이 될 수 있음
  • @Entity가 사용된 영역 역시 도메인 모델이라고 이해하면 됨
  • 다만, 무조건 데이터베이스의 테이블과 관계가 있어야만 하는 것은 아님
  • VO처럼 값 객체들도 이 영역에 해당

Web(Controller), Service, Repository, Dto, Domain 이 5가지 레이어에서 비지니스 처리를 담당해야 할 곳은 ???
→ 바로 Domain

기존에 서비스로 처리하던 방식을 트랜잭션 스크립트라고 함
예) 주문 취소 로직

@Transactional
public Order cancelOrder(int orderId){
    1) 데이터베이스로부터 주문정보(Orders), 결제정보(Billing), 배송정보(Delivery) 조회
    2) 배송 취소를 해야 하는지 확인
    3) if(배송 중이라면){
        배송 취소로 변경
       }
    4) 각 테이블에 취소 상태 Update
}

모든 로직이 서비스 클래스 내부에서 처리됨. 그러다 보니 서비스 계층이 무의미하며, 객체란 단순히 데이터 덩어리 역할만 하게 됨
반면 도메인 모델에서 처리할 경우 다음과 같은 코드

@Transactional
public Order cancelOrder(int orderId){
    //1)
    Orders order = ordersRepository.findById(orderId);
    Billing billing = billingRepository.findByOrderId(orderId);
    Delivery delivery = deliveryRepository.findByOrderId(orderId);

    //2-3)
    delivery.cancel();

    //4)
    order.cancel();
    billing.cancel();

    return order;
}

order, billing, delivery가 각자 본인의 취소 이벤트 처리를 하며, 서비스 메서드는 트랜잭션과 도매인 간의 순서만 보장

스프링에선 Bean을 주입받는 방식들

• @Autowired
• setter
• 생성자

이 중 가장 권장하는 방식이 생성자로 주입받는 방식(@Autowired는 권장하지 않음)
즉, 생성자로 Bean 객체를 받도록 하면 @Autowired와 동일한 효과를 볼 수 있다는 것
그러면 앞에서 생성자는 어디 ???????
→ 바로 @RequiredArgsConstructor에서 해결 👉 final이 선언된 모든 필드를 인자값으로 하는 생성자를 대신 생성