-도입 배경
1차로 완성된 코드에서는 controller 클래스에 여타 서비스 로직들이 노출되어 있다는 문제가 있었다.
아무래도 다른 도메인(amenity, member, comment, like)과 매핑이 많이 되어있는 도메인(BulletinPost-게시물)이다보니 참조 관계가 복잡하게 얽혀 있었다.
DTO로 받은 데이터를 사용해 처리하는 다른 팀원 도메인의 로직을 가져다가 쓰다 보니 컨트롤러 단에서 서비스 로직들이 노출될 수 밖에 없었다.
이에 대해 멘토님께 개선할 수 있는 방법으로 현업에서 사용하는 composite service layer를 넣어보는 방법을 추천받았다.
-Composite Service Layer
Composite Service Layer는 서비스들의 만남의 광장이라고 비유할 수 있다.
결과적으로 Controller단에 존재하던 비즈니스 로직을 완전히 캡슐화할 수 있었다.
또한 필요한 타 서비스 객체들이 composite service에서만 생성이 되면서 각 서비스가 서로의 bean을 주입받지 않게 되었고 그 결과 순환 참조가 방지될 수 있었다.
-개선해야할 점
처음에는 통일성을 위해 Bulletin Post 서비스의 모든 메서드와 내가 맡은 도메인 Like와 Search 의 서비스의 모든 메서드를 Composite Service Layer에 포함되도록 코드를 짜두었다.
이것의 문제점은 각 도메인의 서비스의 일부 메서드들의 모든 로직들이 Composite Service에 포함되면서 그 역할이 repository의 메서드를 불러오는 역할에만 그치게 된다는 점이었다.
이는 코드 낭비로 비효율적이라는 생각이 들어 추후 리팩토링 계획으로 타 서비스와 복잡하게 연관되지 않은 메서드들은 Composite Service Layer를 거치지 않고 각 도메인의 서비스에 해당 로직을 포함시키는 것으로 수정하기로 하였다.
'TIL' 카테고리의 다른 글
자료구조 Tree traversal (0) | 2023.05.17 |
---|---|
자료구조 Graph (0) | 2023.05.05 |
자료구조 Tree (0) | 2023.05.05 |
자료구조 Queue (0) | 2023.05.05 |
자료구조 Stack (0) | 2023.05.05 |