[TIL] MVC : 서비스 계층

👏🏻 Spring MVC : 서비스 계층

 📍 서비스 계층

   - API 계층에서 전달 받은 클라이언트의 요청 데이터를 기반으로 실질적인 비즈니스 요구사항을 처리하는 계층

   - Spring DI를 통해 API 계층과 비즈니스 계층 연동

   - API 계층에서 전달받은 DTO 객체를 비즈니스 계층의 도메인 모델 객체로 변환해서 전달

   💡 Spring MVC

     - 웹 계층을 담당하는 모듈로 서블릿 API를 기반으로 클라이언트 처리하는 모듈

     - 클라이언트 요청을 편리하게 처리해주는 프레임워크

     - Model : 클라이언트의 요청을 처리한 결과 데이터

     - View : Model 데이터를 이용해 웹 브라우저 같은 클라이언트 화면에 보여지는 리소스 제공

     - Controller : 클라이언트 측 요청을 직접 받는 엔드포인트로 Model과 View의 상호작용 역할

      ▪️▪️ Spring MVC 동작 흐름 ▪️▪️

       : 클라이언트가 요청 데이터 전송 → Controller가 요청 데이터 수신 → 비즈니스 로직 처리 → Model 데이터 생성

         → Controller에게 Model 데이터 전달 → Controller가 View에게 Model 데이터 전달 → View가 응답 데이터 생성

   💡 3-Tier Architeure

     ① API 계층 (Controller, DTO)

     ② 비즈니스 계층 (Model, Service)

     ③ 데이터 엑세스 계층 (Repository)

---

📍 DI를 통한 API 계층과 서비스 계층 연동

  - API 계층에서 구현한 Controller 클래스가 서비스 계층의 Service 클래스와 메서드 호출을 통해 상호작용 한다는 의미

  - DTO는 API 계층에서 클라이언트의 요청 데이터를 전달 받고 클라이언트에게 되돌려 줄 응답 데이터를 담는 역할

  - 도메인 엔티티 클래스는 API 계층에서 전달 받은 요청 데이터를 기반으로 서비스 계층에서 비즈니스 로직을 처리하기 위해

     필요한 데이터를 전달 받고 비즈니스 로직 처리후 결과 값을 다시 API 계층으로 전달

 💡 Service

   - 애플리케이션의 비즈니스 로직을 처리하기 위한 서비스 계층은 대부분 도메인 모델을 포함

   - 도메인 업무 영역을 구현하는 비즈니스 로직 처리

   - 클라이언트의 요구사항을 잘 만족하는 Controller클래스를 기반으로 이와 연동하는 Service 클래스를 만드는 것

   - Controller의 핸들러 메서드가 전달 받은 요청을 처리하는 메서드를 Service 클래스에 작성

     ▪️ 도메인 모델

      - 비약한 도메인 모델 + 풍부한 도메인 모델

      - DDD(Domain Driven Design : 도메인 주도 설계)와 관련

     ▪️ 도메인 엔티티 클래스

     - 서비스 계층에서 데이터 엑세스 계층과 연동 하면서 비즈니스 로직을 처리하기 위해 필요한 데이터를 담는 역할

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class Member {
    private long memberId;
    private String email;
    private String name;
    private String phone;
 }

   ▸ @Getter, @Setter 

    : lombok 라이브러리에서 제공하는 getter/setter 메서드를 자동으로 작성해줌

   ▸ @AllArgsConstructor

    : 현재 Member 클래스의 모든 멤버 변수를 파라미터로 갖는 Member 생성자를 자동 생성

   ▸ @NoArgsConstructor

    : 파라미터가 없는 기본 생성자를 자동 생성

---

💡 Spring Bean 등록

  - Controller 클래스에 @RestController을 추가하면 자동 등록

  - Service 클래스에 @Service를 추가하면 자동 등록

  - 생성자 방식의 DI는 생성자가 하나일 경우 @Autowired를 추가하지 않아도 DI 적용

---

📍 Mapper를 통한 DTO 클래스와 Entity 클래스 매핑

 ✍🏻 Controller의 핸들러 메서드가 'DTO클래스를 엔티티 클래스로 변환하는 작업'

                                           → 다른 클래스에게 변환해 달라고 요청하기

 ✍🏻 엔티티 클래스 객체 자체를 응답을 전송하여 '계층 간 역할 분리 X'

                                          → 엔티티 클래스 객체를 DTO 클래스 객체로 변환

 

          즉, DTO 클래스와 엔티티 클래스를 변환해주는 매퍼(Mapper)가 필요 !

---

▪️ MapStruct

 - 매퍼 구현 클래스를 자동으로 생성해주는 코드 자동 생성기

 - 매퍼를 직접 구현할 수도 있지만 MapStrut 같은 매핑 라이브러리를 사용하는 것이 생산성 측면에서 더 우수

 - 매퍼를 자동으로 생성하기 위해서는 매퍼 인터페이스 정의가 필요함

@Mapper(componentModel = "spring")
public interface MemberMapper{
   Mapper클래스에서
   수작업으로 구현했던 메서드들 구현
 }

  ▸ @Mapper

   - 애너테이션을 추가하면 MapStruct의 매퍼 인터페이스로 정의됨

   - componentModel = "spring" 을 지정해주어야 스프링의 빈으로 등록됨

   - 인터페이스를 정의하면 인터페이스의 구현 클래스는 MapStruct가 MemberMapper 인터페이스 기반으로 

      매퍼 구현 클래스 자동 생성해줌

    → 자동 생성된 Mapper 인터페이스 구현 클래스 확인 : Gradle의 build task 실행

---

💡 DTO 클래스와 엔티티 클래스 역할 분리 필요 이유

  ① 계층별 관심사의 분리 

   - 기능에 대한 관심사가 다름

   - DTO 클래스는 API 계층에서 요청 데이터를 전달받고 응답 데이터를 전송하는 것이 주된 목적

   - Entitiy 클래스는 서비스 계층에서 데이터 엑세스 계층과 연동하여 비즈니스 로직의 결과로 생성된 데이터 다룸이 주된 목적

  ② 코드 구성의 단순화

   - DTO 클래스의 유효성 애너테이션이 Entity 클래스에서 사용된다면 JPA에서 사용하는 애너테이션과 뒤섞여 유지보수 어려움

  ③ REST API 스펙의 독립성 확보

   - Entity 클래스를 그대로 응답으로 전달하게 되면 원치 않는 데이터까지 전송될 수 있음