Repository navigation
refactor(afternote): 수신자 흐름 58개 파일을 feature:receiver 로 이전 — 애프터노트 모듈이 타 도메인 열람 관문 소유 #615
Copy link
Copy link
Closed
Copy link
Labels
enhancementNew feature or requestNew feature or request
Description
📜 Overview (Required)
수신자 흐름 코드가 feature:afternote 안에 대부분 들어가 있다. 정작 받을 자리인 :feature:receiver 는 domain 4개 파일만 채워진 채 비어 있다.
실측(2026-07-30, develop b86fb07e):
| 위치 | 파일 수 | 내용 |
|---|---|---|
feature/afternote/presentation/.../receiver/** |
52 | 받은 기록함, 발신자 상세, 열람 신청 4단계(deliveryverification), 수신 상세 3종, 추억 플레이리스트 |
app/screen/receiver/** |
13 | 수신자 홈 — #546 이 다루는 범위 |
feature/afternote/data·domain 내 receiver |
4 + 2 | ReceiverAuthRepositoryImpl, 수신자 예외 타입 등 |
:feature:receiver |
4 | ReceiverAuthRepository·IdentityVerificationRepository·ReceiverDeliveryDocumentUploadRepository·ReceiverAuthModels (domain 뿐) |
:feature:receiver:data·:presentation 은 settings.gradle.kts:56-58 에 등록돼 있고 build.gradle.kts·AndroidManifest.xml 까지 있는데 소스가 0개다. 2026-05-27 "수신자 기능 모듈 분리 및 관련 도메인 로직 이전" 커밋이 domain 만 옮기고 멈춘 상태 그대로다.
왜 지금 정리해야 하나 — 애프터노트 모듈이 다른 도메인의 관문을 쥐고 있다.
receiver/senderdetail/SenderDetailScreen.kt 는 애프터노트 전용 화면이 아니다. delivery-verification 승인 상태를 표시하고 "기록 열람하기" 로 넘기는 수신자 흐름 전체의 관문이라, 이 화면을 통과해야 마음의 기록(feature:mindrecord)·타임레터(feature:timeletter)도 열린다. 열람 신청 4단계(이메일 인증 → 마스터 키 → 서류 업로드)도 마찬가지로 도메인 중립인데 afternote 안에 있다.
이 배치가 실제로 만든 비용:
- 2026-07-30 QA 에서 나온 수신자 결함 6건의 스코프가
afternote·app·mindrecord로 갈렸다(타임레터 수신 열람이 작성자 화면으로 라우팅 — receiver-auth API 미사용·401 을 빈 상태로 위장 #609·fix(app): 수신자 홈 요약 기록 수가 서버 상태 미반영 — 로드 실패를 0 으로 덮고 하위 카운트는 하드코딩 0 #610·fix(afternote): 수신자 애프터노트 목록의 전달 조건 미충족(403) 실패가 원인 미안내 — 재시도만 반복 #611·발신자 상세 '승인일' 이 승인 이후에도 빈 값 — approvedAt 을 주는 record-boxes 미사용 #612·수신자 홈 헤더 액션이 맥락 불일치 — 프로필 아이콘 무동작·설정에 '로그아웃' 만 노출 #613·fix(mindrecord): 수신자 마음의 기록 열람 실패 화면이 데드엔드 — 이탈 수단 부재·서버 응답 원문 그대로 노출 #614). 한 흐름의 결함인데 담당 모듈을 매번 따져야 한다. - 수신자 열람 실패(403 code 2009) 처리가 화면마다 제각각인데(요약=0개, 애프터노트=재시도, 마음의 기록=서버 원문), 공통 처리를 둘 자리가 없다.
작업 내용
feature/afternote/presentation/.../receiver/**52개 파일을:feature:receiver:presentation으로 이전.feature:afternote:domain·presentation의존을 추가한다(수신 상세·플레이리스트가 애프터노트 모델을 참조한다).feature/afternote/data·domain의 receiver 하위(4+2)를:feature:receiver:data·:domain으로 이전.ReceiverAuthRepositoryImpl이 이미 있는 domain 인터페이스와 같은 모듈로 모인다.- 이전 후
AppNavigation.kt·ReceiverNavGraph.kt의 import 갱신. - 파일 이동은 git 이 rename(R)으로 인식하도록 한다.
- screenshot baseline 은 이동 후 CI 와 같은 docker 사이클로 재생성한다.
📌 Child Issue(Optional)
No response
📍 Note (Optional)
- refactor(app): 홈·수신자 홈 화면 feature 모듈 이전 — app 잔존 presentation 정리 #546 선행. refactor(app): 홈·수신자 홈 화면 feature 모듈 이전 — app 잔존 presentation 정리 #546 이 app 의 수신자 홈 13개를
:feature:receiver:presentation으로 옮긴다. 목적지 모듈이 비어 있는 지금 두 이전을 동시에 하면 diff 가 섞이므로, refactor(app): 홈·수신자 홈 화면 feature 모듈 이전 — app 잔존 presentation 정리 #546 으로 모듈에 자리를 잡은 뒤 이 이슈로 afternote 잔여분을 합류시킨다. - 이전 자체는 동작을 바꾸지 않는다. 수신자 열람 실패 처리 통일(fix(afternote): 수신자 애프터노트 목록의 전달 조건 미충족(403) 실패가 원인 미안내 — 재시도만 반복 #611·fix(mindrecord): 수신자 마음의 기록 열람 실패 화면이 데드엔드 — 이탈 수단 부재·서버 응답 원문 그대로 노출 #614 계열)은 코드가 한 모듈에 모인 뒤 별도로 판단한다.
LayerDependencyKonsistTest는 domain 역의존만 검사해 이 배치를 잡지 못한다. 이전 후 모듈 경계 규칙을 추가할지는 별도 판단(refactor(app): 홈·수신자 홈 화면 feature 모듈 이전 — app 잔존 presentation 정리 #546 과 같은 논점).- 노션 프로젝트 구조 의 모듈 트리도 이전 후 갱신 대상이다.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request
Activity
refactor(afternote): 수신자 흐름 전체를 :feature:receiver 로 이전
refactor(afternote): 수신자 흐름 전체를 :feature:receiver 로 이전