[jjunh33]

#️⃣연관된 이슈

• Closes 공지 관리자 기능을 AdminNoticeService로 분리 #144
• 스택: [Feat/#142] 공지 관리자 API 고정 여부 반영 및 목록·상세 조회 추가 #143(게시판(공지) 관리자 API 보완 — 고정 여부 반영, 목록·상세 조회 추가 #142) 위에 쌓았습니다. 아래 PR이 머지되면 base를 main으로 바꾸고 main을 병합합니다
  • [Feat/#142] 공지 관리자 API 고정 여부 반영 및 목록·상세 조회 추가 #143(게시판(공지) 관리자 API 보완 — 고정 여부 반영, 목록·상세 조회 추가 #142, 공지 관리자 API 고정 여부 반영 및 목록·상세 조회) → 이 PR

🎯 해결하려는 문제가 무엇인가요?

NoticeService에 학생 앱의 조회(getNotices, getNotice)와 운영진의 쓰기·검색(create, update, delete, changePinned, search)이 한 인터페이스에 섞여 있습니다. 운영진 전용 기능을 AdminNoticeService로 분리해 학생 앱이 보는 서비스에서 운영진 기능이 보이지 않게 합니다.

❓ 왜 해결해야 하나요?

관리자 API가 늘어나는 중입니다. 지금 규칙({Domain}Service 하나)이면 이후 빌릴게, 사물함, 행사의 관리자 기능도 같은 서비스에 계속 쌓여, 학생용 메서드와 운영진용 메서드가 구분되지 않습니다. 공지를 시작으로 분리 규칙을 정해 둡니다.

⭐ 어떻게 해결했나요?

• core:domain:welfare: AdminNoticeService(공개)와 AdminNoticeServiceImpl(service.impl, package-private)을 추가했습니다. 메서드는 search, getNotice, create, update, delete, changePinned이고, 로직은 NoticeServiceImpl에서 그대로 옮겼습니다(수정 충돌 검사, 소프트 삭제, 아웃박스 기록, 트랜잭션 포함).
• NoticeService/NoticeServiceImpl: 학생용 getNotices, getNotice만 남기고 OutboxWriter 의존을 뺐습니다.
• api:admin-api: AdminNoticeController, AdminNoticeReadUseCase, AdminNoticeWriteUseCase가 AdminNoticeService를 씁니다. 파일 존재 확인 같은 도메인 조합은 이전처럼 UseCase가 맡습니다.
• 문서: coding-style.md의 이름 규칙 표에 Admin{Domain}Service 행을, 2-7절에 분리 규칙을 추가했습니다.

동작 변경은 없고 위치만 옮긴 리팩토링입니다.

🧩 이 PR의 한계 & 트레이드오프

• getNotice(공지 한 건 조회)가 NoticeService와 AdminNoticeService 양쪽에 있습니다. 레이어 규칙 4번(같은 레이어 서비스끼리 호출하지 않음)에 따라 두 구현체가 NoticeRepository를 각각 직접 쓰기 때문에 findById + 예외 변환 세 줄이 중복됩니다.
• 이번에는 공지만 분리했습니다. 회비 등 다른 도메인에 섞인 운영진 메서드(StudentTransferStatusService.search/review 등)는 그대로이고, 규칙 문서에도 "분리하기 전 도메인은 {Domain}Service 하나로 둔다"고 적었습니다.
• 새 테스트를 추가하지 않았습니다. 로직을 그대로 옮긴 것이라 컴파일과 아키텍처 테스트로 구조만 검증했습니다. 로컬에 DB가 없어 실제 기동은 확인하지 못했습니다.

⛓️ 기존 기능에 미치는 영향

• API 경로·요청·응답은 그대로입니다.
• NoticeService에서 create, update, delete, changePinned, search가 사라집니다. 이 메서드를 쓰던 곳은 admin-api의 위 세 클래스뿐이고 AdminNoticeService로 바꿨습니다. 학생 앱(AppNoticeController)은 NoticeService.getNotices, getNotice만 써서 영향이 없습니다.
• 스키마 변경·마이그레이션은 없습니다.

🔀 Edge Case & 실패 시나리오

• 해당 없음. 동작이 그대로라 에러 응답도 바뀌지 않습니다.

📋 검토한 대안과 선택 이유

• admin-api에 AdminNoticeService를 두기: 쓰기 로직이 NoticeRepository, 트랜잭션, 아웃박스를 필요로 하는데 Presentation 계층은 저장소를 직접 참조하지 않아서, 결국 코어의 NoticeService를 부르는 얇은 위임이 되고 UseCase와 역할이 겹칩니다. 코어에 두었습니다.
• NoticeService 하나로 유지: 가장 단순하지만 위에서 말한 대로 학생용과 운영진용이 계속 섞입니다.

💬 리뷰 포인트

• [r] 이름과 위치 규칙(Admin{Domain}Service를 같은 도메인 모듈의 service/service.impl에 둠)이 팀 방향과 맞는지. 이후 도메인에도 같은 규칙으로 갈 예정이라 먼저 정하면 좋습니다.
• [c] 양쪽 서비스에 getNotice가 중복되는 것을 받아들일지
• [a] coding-style.md의 규칙 문구

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Repository: billilge/stream-server/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 785f1bad-7639-4da6-8172-dad4525cbc63

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[tnals0924]

getNotice()가 NoticeService에서 사라지고 AdminNoticeService에만 있게 되었는데 일반 NoticeService에서는 이게 필요없나요?