🌈 [Section3] 3. [ Spring MVC ] 서비스 계층

📕 오늘 배운 내용!

• Cotroller 클래스와 Service 클래스의 연동 with DI
• MapStruct를 이용한 Mapper

---

✏️ 서비스 계층

• API 계층에서 전달 받은 클라이언트의 요청 데이터를 기반으로 실질적인 비즈니스 요구사항을 처리하는 계층
  
  
• Spring의 DI(의존성 주입)를 이용하여 API 계층과 비즈니스(서비스) 계층을 연동하고,
  API 계층에서 전달받은 DTO 객체를 비즈니스(서비스) 계층의 도메인 Entity 객체로 변환해서 전환
  
  

✔️ API 계층과 서비스 계층을 연동한다
➜ API 계층에서 구현한 Controller 클래스가 서비스 계층의 Service 클래스와 메서드 호출을 통해 상호 작용한다

✔️ 서비스 계층은 대부분 도메인 모델을 포함하고 있음
도메인 모델은 빈약한 도메인 모델(anemic domain model) / 풍부한 도메인 모델(rich domain model)로 구분되고,
이는 DDD(도메인 주도 설계, Domain Driven Design)와 관련이 깊음

---

DTO 클래스와 엔티티 클래스의 역할 분리가 필요한 이유

✔️ 계층별 관심사의 분리

• 기능 별로 서로 사용되는 계층이 다름
  ➜ OOP의 단일 책임의 원칙 (SRP)에 따라 더 좋은 OOP 하기 위해

💡 DTO 클래스
- API 계층에서 클라이언트의 Request Body를 전달 받고 클라이언트에게 되돌려 줄 응답 데이터를 담는 역할
- API 계층에서 요청 데이터를 전달 받고, 응답 데이터를 전송하는것이 주 목적

---

💡 Entity 클래스
- 서비스 계층에서 데이터 액세스 계층과 연동하면서 비즈니스 로직을 처리하기 위해 필요한 데이터를 담는 역할을 하는 클래스
- API 계층에서 전달 받은 요청 데이터를 기반으로 서비스 계층에서 비즈니스 로직을 처리하기 위해 필요한 데이터를 전달 받고,
비즈니스 로직을 처리한 후에는 결과 값을 다시 API 계층으로 리턴해주는 역할

( DTO 클래스와 비즈니스 클래스 합친 역할 )

✔️ 코드 구성의 단순화

• DTO 클래스에서 사용하는 유효성 검사 애너테이션이 Entity 클래스에서 사용이 된다면 JPA에서 사용하는 애너테이션과 뒤섞인 상태가 되어 유지보수하기 상당히 어려운 코드가 될 것

✔️ REST API 스펙의 독립성 확보

• Entity 클래스를 응답으로 전달하게 되면 원치않는 데이터까지 전달될 수 있음 Ex. password
  ➜ DTO 클래스를 사용하여 응답으로 전달해 원하는 정보만 제공 가능

---

✏️ Mapper

• DTO 클래스처럼 Java Bean 규약을 지키는 객체들 간의 변환 기능을 제공
  ( 역할 구분을 위해 DTO ➜ Entity / Entity ➜ DTO 의 변환을 이루어줌 )

 

✏️ MapStruct

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

❗ MapStruct 사용을 위해서는 아래 의존 라이브러리를 build.gradle 파일의 dependencies 에 추가해야함

implementation 'org.mapstruct:mapstruct:1.4.2.Final'
annotationProcessor 'org.mapstruct:mapstruct-processor:1.4.2.Final'​

• 이를 사용하여 정의한 Mapper 인터페이스에는 @Mapper 애너테이션을 붙여 MapStruct의 매퍼 인터페이스로 정의될 수 있도록 해야하고,
  
  
• @Mapper 애너테이션의 애트리뷰트로 componentModel = "spring"을 지정해주어 Spring Bean으로 등록될 수 있도록 해야함
  
  
• 이 MapStruct가 자동으로 생성해준 Mapper 인터페이스의 구현 클래스는 자동으로 생성되어 build > classes 디렉토리 내에 Mapper 인터페이스가 위치한 패키지 안에 MapperImpl이라는 이름으로 생성됨

---

😜 비즈니스 계층과 API 계층 연동 실습

• projects 폴더의 be-template-service-layer 참고!
• 실습 과제는 git 폴더의 be-homework-mpaaer 참고!
  
  

이전 실습에서 DTO 클래스를 사용해 클라이언트의 요청을 받아 다시 요청을 전달하도록 Controller에 DTO 클래스를 주입하여 사용했었는데,

이는 OOP의 SRP(단일 책임 원칙, Single Responsibility Principle)에 따라,
각 클래스는 하나의 역할만 하도록 만드는 것이 좋음

이전 실습에서 했던 방법은 DTO 클래스가 클라이언트의 요청도 받고, 이를 Entity 객체로 변환 시켜주는 역할까지 함
( API 계층과 Service 계층 구분 불가 )

따라서, 이 두 계층을 분리시키기 위해

❗ Service 클래스와 Entity 클래스를 따로 만든 후, ** MapStruct를 이용한 Mapper 인터페이스를 사용**하여 DTO - Entity 간의 변경을 해줄 것임

그리고 Controller 객체에 생성자의 파라미터로 Service 객체, Entity 객체 모두 의존성 주입(DI)을 통해
각 핸들러 메서드의 Body에 DTO 클래스를 Mapper로 이용해 Entity 객체로 바꾸고, 이를 Service 클래스와 연동한 후,
리턴값으로 그 바꿔 연동한 Entity 객체와 상태코드를 같이 넣어주면 됨

✔️ Lombok 기능들 (애너테이션)
[참고] https://projectlombok.org/features/

---

⚠️ 프로젝트 생성 시 주의할 점

Spring Boot initialize로 프로젝트 생성시, @SpringBootAplication 애너테이션이 붙은 Application.class 가 생성됨

이 @SpringBootAplication 애너테이션이 붙으면, 그 클래스부터 그 하위를 모두 검사하며 @Component들 찾아서 검사함

그래서 Application.class 는 최상위 폴더(프로젝트 이름 폴더) 바로 밑에만 들어가고 어떠한 폴더에도 들어가면 안됨 !

➜ 한 폴더에 들어가게 되면 그 폴더의 하위 파일들만 검사하게 되어서 모든 클래스들이 Application.class 로부터 하위로 쭉 시작되어야 함

---

🌈 느낀점

어제보단 뭔가 양이 많아져서 구조가 한눈에 잡히지 않았지만 그래도 하면서 점점 깨달아가고 이게 왜 이렇게 이어져 있는지 이해가 되는 게 재밌다 !
확실히 개념만 공부하는 것 보다 코드를 직접 써보면서 하니까 기억도 이해도 더 잘 되는 것 같다 ㅎㅎ

 

( 본 게시물은 2022/10/25에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90