패키지 분리

• 파사드 패턴을 당장 도입하기에 시간적인 여유가 없다
• 최소한의 분리 → ( 기능을 만드는 위치는 행위의 목적이 되는 도메인에 만든다 )
• 서비스에서 행위자를 기준으로 클래스를 나눈다 (review → reviewService, reviewClubService, reviewMemberService….)
• 클럽에서 멤버를 조회하는 기능? → 멤버에서 만든다 ( member → memberClubService)
• service 계층이 의존할 수 있는 클래스? → 공통모듈, 각각의 repository 클래스
• memberClubService → memberRepo, ClubRepo, s3Service, redisService…..
• reviewClubService → reviewrepo, clubrepo, s3…..

결론

• 기능은 행위의 목적이 되는 도메인에 만든다 ex) 클럽의 리뷰를 조회? review, 회원의 클럽을 조회? club
• 컨트롤러는 하나의 서비스 메서드를 의존한다
  • 컨트롤러명은 서비스명을 따라간다
• 서비스는 행위자를 기준으로 클래스를 여러개 나눈다.
  • 서비스명은 도메인명 + 행위자명 + sevice
  • ex) 클럽의 리뷰를 조회? reviewClubService, 회원의 클럽을 조회? clubMemberService
• 각각의 서비스는 서비스 끼리 의존성을 가질 수 없다.
  • 예외적으로 공통모듈의 서비스는 가질 수 있다. (s3, redis, commonCode…)