관리자 기능 추가에 따른 패키지 구조

[LJW25]

관리자 페이지 기능 추가를 기획하면서, 해당 기능과 관련된 코드를 어떤 패키지에 두는 것이 옳은가에 대해 의견을 묻고자 해당 디스커션을 파게 되었습니다!
기획에 대한 배경과 계획은 이슈 #778 를 참고해 주세요.

---

기본: hanglog/admin 패키지를 추가한다.

(커밋 꼬임 등 영향이 크기 때문에 현재단계에서 멀티모듈은 시도하지 않는다.
추후 아무도 백엔드 코드를 건드리지 않는 상황이 온다면 그때 고려 한다.)

---

방향

1. admin 패키지 내에 관리자기능을 모두 추가한다.

- AdminController가 관리자 로그인, 관리자 계정 추가&관리, 3종 데이터(City,Category,Currency)의 CRU API를 모두 가진다.
- 관리자 로그인을 위한 ArgumentResolver를 admin 패키지가 가진다.

2. admin 패키지와 admin-login 패키지를 분리한다.

- AdminController가 관리자 계정 추가&관리, 3종 데이터(City,Category,Currency)의 CRU API를 모두 가진다.
- 관리자 로그인을 위한 ArgumentResolver를 admin-login 패키지가 가진다.
- 관리자 로그인을 위한 API를 admin-login의 AdminLoginController가 가진다.

3. admin 패키지와 admin-login 패키지를 분리하고 3종 데이터의 관리를 각각의 패키지로 책임을 분리한다.

- AdminController가 관리자 계정 추가&관리 API를 가진다.
- 관리자 로그인을 위한 ArgumentResolver를 admin-login 패키지가 가진다.
- 관리자 로그인을 위한 API를 admin-login의 AdminLoginController가 가진다.
- 3종 데이터(City,Category,Currency)의 CRU API를 City, Category, Currency 패키지의 각 Controller가 가진다. 

---

추가정보

• 3종 데이터의 API는 @AdminOnly 어노테이션을 사용해 접근을 제어한다.
• 관리자 계정 관리 API는 @MasterOnly 어노테이션을 사용해 접근을 제어한다.

[LJW25]

이오’s 의견

1번으로 갈수록 admin 패키지의 역할이 커지는 대신 일반 기능과 분리가 확실하고, 3번으로 갈수록 책임의 분리가 명확한 대신 일반 서비스와의 결합이 커집니다. 개인적으로 현재는 3번이 가장 끌리는데(책임 분리때문에), 기존의 서비스 코드에 영향이 가는 만큼 다른 분들의 생각을 먼저 여쭤봐야 하는게 맞는것 같아요. 3가지 이외에 다른 것도 좋습니다. 의견 부탁드립니다.

[jjongwa]

저는 1번 쪽에 맘이 가긴 하는데(물론 이오가 저보다 오래 생각해 봤겠지만,,!)
책임의 분리라는 측면에서 조금 더 자세히 설명해 주실 수 있나요?
각 도메인(City, Category, Currency)에 대한 CRU 로직을 admin 패키지가 모두 가지고 있는것 보다 각각의 패키지가 관리하고 있는게 더 자연스럽다는 느낌일까요?

[LJW25]

네 맞습니다!
관리자 권한의 기본 데이터 관리 API는 결국 city, category, currency에 대한 CRU API이기 때문에, 각각의 패키지에서 관리하는게 적절한 책임의 분리라고 느꼈어요.
새로운 도시를 추가하는 상황을 예로 들면, 처음 API에 접근 할 때 해당 계정이 admin 권한을 갖고 있는지 어노테이션을 통해 확인하고, 이후에는 city repository를 사용하게 됩니다. 이러한 방식으로 갈 경우 AdminService가 CityRepository, CategoryRepository, CurrencyRepository를 모두 가지게 되는 것이 너무 커진다고 생각했습니다.

근데 한편으로는 1번이 기존 코드에 영향을 덜 미치는 방식이라 생각해서 1번도 납득이 갑니다..! 그래서 모두의 의견을 들어보고 싶었어요!

[LJW25]

다시 고민을 해보면서 지금 구현하려는 Admin이란 도메인 자체가 원래 큰거니까 1로 가도 자연스럽다는 생각도 점점 드네요..? 패키지 의존이 많아진다는게 조금 걸리긴 한데 그것도 양방향이 아니라서 문제는 아니기도 하구요. Trip 패키지 같은 느낌이다 생각하면 별로 어색하진 않은 것 같아요.
으아아 내일까지 다른분들 의견도 더 여쭤보겠습니다!

[mcodnjs]

오오오 흠 .. 저는 admin이랑 admin-login 패키지 자체를 분리하는 것보단 admin 패키지 하나에서 서비스 단으로 관리자 관리 + 로그인 기능 등을 분리하는게 더 끌리긴 해요! 아직 admin 기능의 파급력이 얼마나 될지 몰라서 더 커지면 그 때 분리를 고려해봐도 좋을거 같아요 ㅎㅎ CRU API에 대한 부분은 .. 각 패키지에서 제공하던, admin 패키지 내부에서 구현하던 선호는 없지만 .. admin 패키지 내부에 있으면 확 와닿는 장점이 저희가 코드 관리하기 편하다는 장점이 있을거 같네요오 ㅎ.ㅎ..

[hgo641]

오... 전 1번, 3번 짬뽕인데...
일단 admin이랑 admin-login은 한 패키지에 있어도 괜찮다...고 생각했어요 admin이라는 도메인에 하나로 묶여있어도 어색하지 않아서?...

그런데, 3종 데이터(City,Category,Currency)의 CRU API를 City, Category, Currency 패키지의 각 Controller가 가진다. <- 얘네는 City, Category, Currency 패키지에서 구현하고 admin패키지가 이쪽에 의존하는 방향을 생각했어요! (근데 Controller가 있는 건 아니고, Service만 City, Category, Currency 패키지에 존재. Admin의 컨트롤러에서 해당 Service들 호출하는 방향 생각함. 엇? 1번이 이걸 말한건가?)

나중에 City, Category, Currency CRU가 admin외에 다른 곳에서도 필요해지면 중복으로 코드를 작성해야하니까?... City, Category, Currency CRU는 각 도메인 패키지 내부에 있는 게 좋겠다고 생각했습니다! (근데 사실 admin외에 다른 곳에서도 활용될 가능성이 희박하긴해서... 1번으로 가도 괜찮다 입장!)

[jjongwa]

저도 컨트롤러는 한곳에 모아두고 서비스들은 각 패키지에 구현 후 가져다 쓰는게 좋아 보이네용

[LJW25]

여러분들 의견 감사드립니다.
모든걸 반영한 PR! 바로 여기! PR 바로가기
따끈따끈한 코드를 리뷰할 기회!

[hgo641]

모두 반영하다니 굉장한걸?