refactor(S15P11A705-202): follow 전용 예외를 follow 도메인으로 옮긴다

[minyongP]

Closes #89

docs/development/error-handling.md:36이 "도메인별 구체 예외는 해당 도메인에서 베이스를 상속합니다" 로 정했는데 follow 전용 예외 둘만 global/exception에 있었다. 동작은 정상이었고 이 PR도 동작을 바꾸지 않는다.

(a)를 택한 이유 — 비용 계산이 뒤집혔다

이슈는 (a) 코드 이동 / (b) 규약 수정을 놓고 결론을 내지 않았다. (b)가 "코드를 안 건드리는 싼 쪽"으로 보이지만 확인해 보니 그렇지 않았다.

domain/ai/exception/AiSearchException.java
domain/auth/exception/UnsupportedSocialProviderException.java

두 도메인이 이미 그 규약을 지키고 있다. "모든 예외를 global에 모은다"를 새 규약으로 세우면 밖에 있는 이 둘이 새로 어긋나고, 그러면 #89가 없애려던 "규약과 코드가 말없이 다른 상태"가 그대로 재생산된다. 즉 (b)도 파일 2개를 옮겨야 한다 — 방향만 반대다. 게다가 AiSearchException은 AI 담당 경계에 걸쳐 있어 합의가 선행된다.

DeleteConfirmationRequiredException은 record·collection 두 도메인 공용이라 global/exception에 남는다. 이것이 규약이 이미 제대로 작동한다는 증거다 — 공용은 global, 전용은 도메인.

검증 — 새 테스트를 더하지 않았다

순수 이동이라 RED을 만들 수 없다. 다만 기존 테스트가 완료 조건이 요구하는 것을 정확히 지키고 있다.

테스트	단언
followingMyOwnShelfIs422	422 + SELF_FOLLOW_NOT_ALLOWED
duplicateFollowIs409WithoutDuplicateRow	409 + DUPLICATE_FOLLOW
concurrentDuplicateFollowIs409NotServerError	동시 요청에서도 409 + DUPLICATE_FOLLOW

셋 다 상태와 코드를 양쪽 다 본다. 이동이 ErrorCode 배선을 깨뜨렸다면 빨개진다. 같은 단언의 사본을 더하는 것은 잡음이라 더하지 않았다.

GlobalExceptionHandler는 BusinessException 베이스로 받으므로 패키지를 가정하지 않고, ArchUnit류 패키지 검사도 없어 따라 고칠 것이 없었다. BusinessException의 생성자가 protected라 다른 패키지의 하위 클래스에서도 그대로 호출된다.

일부러 하지 않은 것

@NullMarked를 새 패키지에 붙이지 않았다. 형제인 domain/ai/exception·domain/auth/exception은 붙어 있지만, domain/follow에는 package-info.java가 하나도 없다. @NullMarked는 하위 패키지로 상속되지 않으므로 예외 패키지만 마킹하면 BD-29가 재검토 트리거로 지목한 "마킹 패키지 혼재" 를 이 도메인 안에 만든다. follow 도메인 전체를 마킹할지는 별 티켓의 판단이라 보고 남겨 둔다.

완료 조건 대조

• DuplicateFollowException·SelfFollowNotAllowedException이 domain/follow 아래에 있다
• DeleteConfirmationRequiredException은 global/exception에 남아 있다
• 두 예외가 만드는 오류 응답의 code와 HTTP 상태가 이동 전과 같음을 테스트로 확인한다
• ./gradlew clean check --no-daemon — 409개 통과

🤖 Generated with Claude Code