개발일지 - 8일차: daily Check 추가

3일간의 연휴동안 코로나에 걸려버려서 추가적인 공부를 못했다... 역시 건강해야 뭘 하던지 하는걸 느꼈다.

 

8일차에는 이전에 작성하던 resolution에 일일 달성 체크 항목을 구현하기 위해 Daily-check 도메인을 추가했다.

 

코드는 아직까지는 기본적인 CRUD만 작성하고 서비스와 리포지토리를 기본적인 요소만 추가했다.

 

다른 팀원이 작성한 코드를 리뷰하던 도중 한가지 팀끼리 정할 코드 방칙이 있었다.

 

이전 4일차에서(4일차는 블로그에 작성하는걸 잊어먹었다.. 관련 내용은 다시 포스팅할 예정이다.) 튜터님에게 질문했던 내용이 from과 of메서드의 위치이다.

 

from() 메서드는 Entity를 DTO로, of() 메서드는 DTO를 엔티티로 변환하는 메서드이다. 원래 해당 메서드는 엔티티 클래스 내부에 있었지만, 엔티티에는 DB에 관련된 내용만 최대한 넣는게 SRP원칙에 더 가까운 설계라고 하셨다.

 

사실 어디에 어떤 메서드를 집어넣느냐는 개발자마다 다르기 때문에 정해진 정답이랄게 없다고 한다. 따라서 팀원과 회의 후 DTO에 변환 메소드를 넣기로 했다.

 

4일차엔 이렇게 DTO에 메서드를 넣기로 결정했지만, 이번에 코드를 작성하면서 update 같은 엔티티에 직접적인 변경이 필요한 api의 경우 기능을 수행하는 메서드의 위치는 어디로 해야 할지 고민이었다.

 

기존엔 엔티티 내부에 선언해 놓고 사용했지만 SRP 원칙에 어긋나는 위치가 아닌가 하는 생각이 들었다.

 

이에 튜터님께 조언을 구해봤는데, 메서드 자체는 엔티티에 있어도 상관은 없지만, 메서드에 주어지는 인자를 바꿔줘야 한다고 하셨다.

예시를 보자.

수정 전 코드

 

기존에 작성한 resolution의 수정 api에서 사용하는 메서드이다. 인자로 RequestDTO를 받고 있는데, 이는 엔티티와 DTO의독립성을 해칠 수 있는 코드이다.

 

이는 아래와 같은 방법으로 해결할 수 있다.

 

수정 후 코드

 

인자로 dto대신 각 필드에 맞는 개별의 인자를 받는 식으로 구성함으로써 코드의 의존성을 낮출 수 있다.