merge: (#798) 모범학생 투표 집계 자동화 및 도메인 레벨 점수 계산 구현

[pji-min]

작업 내용 설명

• 기숙사 모범학생 투표 집계가 수작업으로 이루어져 관리 부담과 오류 가능성이 있었습니다.
• 복잡한 조건의 투표 결과를 안정적으로 자동 집계할 수 있는 구조를 구현했습니다.

주요 변경 사항

배치 처리 도입

• @Scheduled 기반 배치 처리를 도입하여 투표 집계를 자동화

로직 분리

• QueryDSL로 조회 로직을 분리하고 도메인 레벨에서 점수 계산을 수행
• 계산·조회·표현 로직을 명확히 분리하여 유지보수성 개선

결과물

• 투표 집계 자동화로 수작업 오류 가능성 제거 및 관리 부담 감소
• 도메인 레벨 점수 계산으로 비즈니스 로직의 응집도 향상

체크리스트

• 어플리케이션 구동(혹은 테스트)시 오류는 없나요?
• 생성된 코드에 Javadoc 주석을 추가 하였나요?
• 생성된 코드에 대한 테스트 코드가 작성 되었나요?

관련 이슈

• modelStudentList

[tedsoftj1123]

모범학생 후보의 기준이 뭔지 알수있을까요?

[pji-min]

이달에 벌점을 받지 않은 학생입니다

[ilyoil2]

브랜치 명 이런식으로 하지 말고

이런식으로 해주세요

[tedsoftj1123]

이달에 벌점을 받지 않은 학생입니다

음 상황을 제가 자세히 알지는 못하지만 코드만 봤을 땐 조회할때마다 말씀하신 조건으로 필터링을 하는거같은데 "이달의" 모범학생이라면 한달에 한번만 계산되도 될거같은데요, 모범학생이라는 정보를 다른 테이블에 분리하거나 student에 model이라는 boolean필드를 만들어서 저장해둔다면 조회할떄 이렇게 무거운 쿼리를 계속 날리지 않아도 될거같습니다...

• 현제 모범학생조회는 그냥 student필드를 조회하고있는거같은데 나중에 투표? 같은거도 할거같은데 고것은 어떻게 구현하실건지? 가궁금합니다

[tedsoftj1123]

컨벤션좀 이상한게 보이는데 제 기억상으로 아마 ktlint돌리면 코드 컨벤션은 자동으로 다 고쳐졌던걸로 기억합니다

[pji-min]

투표 구현하는 부분은 제가 담당하고 있는 부분이 아니라서 한번 얘기해보고 답변 드리겠습니다
그리고 그 외의 피드백 주신 부분 참고해보겠습니다 감사합니다!

[pji-min]

얘기해본 결과 사감선생님께서 모범학생 투표를 실행하시면 클라이언트에서 모범학생 리스트를 요청하게 됩니다 이 요청이 투표를 진행하는 API로 전달되고 해당 API에서는 투표를 처리하여 모범학생을 선정하게 된다고 합니다!

[tedsoftj1123]

얘기해본 결과 사감선생님께서 모범학생 투표를 실행하시면 클라이언트에서 모범학생 리스트를 요청하게 됩니다 이 요청이 투표를 진행하는 API로 전달되고 해당 API에서는 투표를 처리하여 모범학생을 선정하게 된다고 합니다!

음 그렇군요 저는 그냥 달마다 자동으로 생기는 걸로 생각했는데.. 아니였군요..

일단 저는 이 API가 student도메인에서 제공하는 모범학생 조회 API로 느껴지는데요
pji-min(이름을 몰라서.. ㅈㅅ) 님이 설계하신바로는 /vote/candidate-list/YYYY-MM-DD 로 이 URL만 봤을땐 투표 후보?로 느껴지는데 response로 student모델이 내려오고있으니 path가 그렇게 직관적으로 느껴지지 않네요... 수정한다면 /votes/model-students/YYYY-MM-DD 이런 path면 좀더 직관적이지 않을까 생각됩니다.

근데 앞서 말했듯 모범 학생이라는게 꼭 투표 도메인 안에 있나? 라고 생각해보면.. 지금은 이 모범학생 조회가 투표할때만 사용되는 API라면 어느정도 납득이 되는데 만약 나중에 이 API가 투표페이지 말고 다른곳에서 쓰인다고 했을때를 생각해보면 갑자기 뜬금없이 votes/로 시작하는 API를 찌르게되기때문에... API가 직관적이게되지 않을거같은데요,

/students/models/YYYY-MM-DD 뭐 이런식으로 students안에 두는 방법을 쓴다면 위 케이스에선 딱히 어색한 부분은 없을거같네요. 선택은 한번 다른분들이랑 상의해보고 지금 상황에서 가장 옳다고 생각하시는거 아무거나 하셔도 될거같습니다.

• 코드에 대한 피드백
  지금 전체적으로 봤을때 ModelStudent라는 도메인을 아예 새로 정의하시고 관련 adapter들을 만드신것 같은데... 사실 모범 학생은 그냥 학생인거잖아요? 필터링 조건이 추가될뿐인.. 그래서 뭐 나중에 이 도메인이 진짜 커지면 분리할 수 도 있겠는데 현제로선.. student 도메인쪽에 함수(조회 메서드 등등)를 추가하는게 좋아보여요
  /students/models/YYYY-MM-DD APi를 이렇게 가기로 했으면 그냥 student에다가 Usecase하나 만들어서 구현하면 되는거고
  /votes/model-students/YYYY-MM-DD 이걸로 가기로했다면 usecase는 vote에 만들되 그 usecase에서 student의 service를 사용하는 느낌으로

[pji-min]

한번 상의 해보겠습니다! 피드백 감사합니다~

[pji-min]

students 도메인 안에 두는 방법으로 진행하게 될 것 같습니다 감사합니다

[pji-min]

넵 알겠습니다 감사합니다~

[zios0707]

살짝 코드 리뷰를 해봤는데 전체적으로 프로젝트에 대한 이해도, 코틀린 언어 이해도 전부 미흡해 보입니다.

DMS 코드랑 DMS 노션에 있는 프로젝트 설계 문서 전부 복습하시는 걸 적극적으로 추천합니다.
아니면 코틀린으로 토이프로젝트를 만들어 DMS 설계를 따라해보며 개발하시는 것도 프로젝트 구조 이해에 매우 도움이 될 것이라 생각합니다.

[zios0707]

제 예상과 다르게 수정을 하시긴 하셨습니다만 아슬아슬하게 RESTful이긴하니까 lint 작업만 하시고 코드 스타일 부분부분만 수정해주시면 approve 해드리겠습니다.

최상위 모듈에서 detekt 작업을 실행해주시고 커밋해주시기만 하시면 될 것 같습니다.