일단 내가 리팩토링을 하는 이유

테스트 코드를 짜는데에 있어서 의존성 및 여러 역할과 책임이 제대로 분리되지 않아서 어려움이 있다.

더불어 비교적 간편한 단위테스트를 위해서는 리팩토링이 필요하다.

객체, 클래스 설계시에

• TDA 원칙 (묻지말고 시켜라) - 행동을 우선시 생각하자
• SOLID 원칙을 고려하자!
• Likeable 인터페이스를 통해 여행 계획, 후기, 댓글을 좋아요 기능 관련해서 묶는다.
  • 결국 User와 Something을 좋아요 한다.
  • 한번 묶어볼까? 에서 시작했다.
  • 재사용성: Likeable 인터페이스를 통해 여러 도메인 객체에 좋아요 기능을 쉽게 적용
  • 유연성: 새로운 도메인 객체가 생겨도 Likeable 인터페이스를 구현하면 좋아요 기능을 쉽게 추가
  • 단일 책임: 좋아요 기능이 분리되어 각 클래스는 자신의 핵심 책임에 집중

안티패턴

• Request , Command (순환참조를 해결)
• 비즈니스 로직은 도메인 모델에 위치해야 한다.

서비스 (스마트 서비스 x)

• 스프링의 서비스 컴포넌트는
• 서비스와 관련된 행동 조언

일정 부분 API 변수명 변경

• 클래스명 변경
• 도메인 → 계층 기반 구조로 변경