naming... 그 심오한 세계에 대하여.

클래스명.... 언제나 분쟁의 소지가 가득한 녀석이죠.

전 그냥 제 멋대로 (정확히는 어차피 제 개인플젝이라) 아래와 같이 규칙을 세웠습니다.

controller 쪽의 클래스명은 get/post/put/patch 를 앞에 붙임
service쪽은 create/read/update/delete 를 붙임


@GetMapping("/{memberId}")
public MemberResponse getMember(@PathVariable Long memberId) {
  return memberService.selectMember(memberId);
}

눈치 채셨겠지만, 컨트롤러쪽은 http method에 가까우니 get, post 등을 붙인거고

service단은 DB단에 가까우니 CRUD를 넣어줌.

뭐 이런 똥같은 논리 인데,

더 경험많은 친구넘에게 컨설팅 받으니 '굳이 그럴필요 있음? 걍 똑같이 getMember로 통일 ㄱㄱ 하지??

라고 설득 당해버렸습니다.

실은 클래스명을 둘다 동일하게 쓴다는 것도 저는 선호하지 않아서.....

저는 좀 자세히 길게 쓰는 주절주절 스탈이라....

당연 더 잘하는 친구라 깨갱하고 따라야 하겠지만...

그래도 최후의 보루로 문의드립니다.

이런 스탈은 안쓰는건가요? ㅠ

안녕하세요. 호돌맨입니다.
질문을 남겨주셔서 감사합니다.

1. controller

저도 질문민수님이 남겨주신것 처럼 네이밍하는 경우가 많습니다.
그런데 controller이름 자체가 MemberController라면
getMember, updateMember로 하지 않고 get, update, delete 등으로 네이밍합니다.
그런데 이런 네이밍 자체가 모든 상황을 100% 커버할 수 없습니다. 예를들어 MemberController에서 회원정보를 수정하는 두 가지 기능이 있을 수도 있습니다. 예를들면

1. 회원정보 수정 PATCH /v1/members/{memberId}
이런 경우 MemberController.patch()

2. 회원의 비밀번호 수정 PATCH /v1/member/{memberId}/password
이런 경우 patchPassword() 또는 changePassword()라고 합니다.

기능이라는 건 계속 변경되기 마련이고.. 그래서 네이밍룰도 언제나 바뀔수 있다고 생각합니다.

2. service

이건 해당 서비스에 맞는 네이밍으로 가져가는 편 입니다.

글 관련 서비스에 작성하는 기능이라면 PostService.create로 할 수도 있겠지만, PostService.write()로 할 수도 있습니다.
글을 조회하는 기능이라면 PostService.get(), 그런데 글을 조회함과 동시에 DB에 조회수1을 증가하는 서비스라면 PostService.read() 가 될 수도 있겠죠.

그리고 Controller와 마찬가지로.. 서비스명이 MemberService라면 이미 Member라는 의미가 포함되어 있습니다. 그래서 MemberService.select() 나 MemberService.get() 정도로 할 것 같습니다.

3. 그러니깐

이렇게 저렇게 네이밍 룰이 딱 정해져 있냐?! 아니요 그렇지 않습니다. 최소한의 룰은 있으면 좋은데 앞으로 추가,수정,삭제될 도메인까지 걱정하며 룰을 정할 수 없습니다. 그렇기 때문에 적절한 코드리뷰를 통해 의견을 맞춰가는 게 중요하다고 생각합니다.

간혹 '내가 보기엔 병신같은 룰 인데 꼭 저 사람이 말한대로 해야하나?' 싶을때도 있으실 겁니다. 그런데 규칙이라는게 다 수가 이해할 수 있는 방향대로 가기 마련이져 그러니깐 너무 상심 안하셔도 됩니다. 현재 정해진 네이밍 룰이 영 맘에 안드시면 좋은 방향이 뭔지 팀원들을 설득해서 바꿔보는것도 앞으로 개발자로 일 하시는데 도움이 될 수 있습니다.

감사합니다.

인프런 커뮤니티 질문&답변

1. controller

2. service

3. 그러니깐