S3U2 [Spring MVC] 서비스 계층

[서비스 계층에서의 DI]

🦖 서비스 계층은 도메인 업무 영역을 구현하는 비즈니스 로직과 관련있다. 보통 Controller로 주입되어 사용된다. Controller 핸들러 메서드의 책임과 역할을 생각해보면 DTO-Entity 간의 변환 작업이 해당 메서드에서 이루어지는 것은 바람직하지 않다. 그래서 보통 매퍼 클래스를 따로 생성해서 매핑을 진행한다. 도메인이 늘어날 때마다 일일이 매퍼를 작성해야하는 번거로움이 문제가 되는데, 이를 해소해주는 라이브러리가 매핑 라이브러리들이다. 그 중에서도 MapStruct를 사용했다. ModelMapper라는 라이브러리도 많이 쓰인다고 하는데, 런타임 시점에 리플렉션 API를 이용해 매핑을 진행하기 때문에 컴파일 시점에 생성되는 MapStruct보다 성능 면에서 뒤쳐진다고 한다.
MapStruct를 사용하기 위해서는 라이브러리 의존을 추가해주고, Mapper 인터페이스를 정의해서 @Mapper(componentModel = "spring")을 달아준다. 이 속성을 적어주면 Spring Bean으로 등록된다.
DTO와 Entity는 사용되는 계층이 다르다. 각각 API 계층, 서비스 계층에서 사용된다. 즉 관심사가 다르다는 이야기이다. 계층별 관심사를 분리해주는 것이 바람직하기 때문에 둘을 구분해 변환하면서 사용해주는 것이 좋다. 또, 이렇게 되면 코드가 단순해진다. 추후에 배우겠지만 Entity 클래스에는 여러 JPA 애너테이션들이 붙는데, 유효성 검사와 뒤섞이며 유지보수가 어려워지는 것을 막는다. 또, 데이터 액세스 계층에서 반환된 Entity를 그대로 응답에 사용할 경우 원치 않는 정보까지 전송하는 일이 생길 수 있기 때문에 원하는 정보만 적절히 DTO로 변환하여 응답 데이터로 환하는 것이 좋다.

실습 위주로 진행된 유닛이었기 때문에 정리 내용이 길지는 않다. 회고를 작성하면서 깨닫게 된 것은 Entity도 비즈니스 로직을 포함하는 Domain Entity와 데이터베이스 처리를 위한 Entity(영속적)로 나누어서 볼 수 있다는 것이다. 회고를 작성하는 지금 JDBC를 학습한 상태인데 VO라는 개념은 어디에 적용되는 건지 좀 헷갈렸는데 도메인 Entity라 생각하니 의문이 조금 해소되었다. 사실 학습 컨텐츠에도 "서비스 계층에서 데이터 액세스 계층과 연동하면서 비즈니스 로직을 처리하기 위해 필요한 데이터를 담는 역할을 하는 클래스"라고 도메인 Entity를 설명해놓은 글이 있긴 했다ㅎㅎ 꼼꼼히 보지 않았구나... 후후 이런 게 회고 작성의 순기능인 것 같다.

---

🙏 Unit 2. 서비스 계층을 마치고!

짧았지만 많이 놀라웠던 유닛~! 왜냐면 MapStruct라는 라이브러리에 대해 알게 되었기 때문이다! 이전에 나는 DTO를 도메인 객체와 분리해야한다는 사실은 알고 있었지만, get__()을 사용해서 손수 매핑을 해주었다. 매퍼 라이브러리가 있다는 사실조차 모르고 있었다. 그래서 이번 유닛 실습도 되게 재미있었다! 그리고 이번 유닛을 학습한 날 TIL을 작성하다가 리플렉션에 대해 조금 찾아봤는데, 깊게 알아보지는 않았지만 그것도 새로운 개념이라 흥미로웠다. (나한테 아직 많이 어려운 내용이긴 하다ㅠ_ㅠ))) 무튼 계속계속 실습을 하고 연습을 해보니까 생성자를 통한 DI에 많이 익숙해졌다는 생각이 든다! Spring을 시작하고서는 자꾸자꾸 재미있는 내용만 나온다. 앞으로도 재밌어주라...🥹 서비스 계층 회고 끝