[리팩토링 #8] 1차 리팩토링 마무리와 남은 설계 부채

Об этом предложении

처음에는 프로젝트가 끝난 뒤 패키지 구조를 다시 정리하는 정도로 생각했다. 하지만 전체 코드를 다시 확인하면서 패키지 위치뿐만 아니라 문서, 네이밍, 코드 작성 기준까지 서로 다른 부분이 보였다. 그래서 1차 리팩토링에서는 기존 동작을 최대한 유지하면서 프로젝트 전체를 같은 기준으로 읽을 수 있게 만드는 것 까지를 범위로 잡았다. 1. 1차 리팩토링에서 한 것 구분 Before After 최상위 구조 기능과 기술 패키지 혼재 기능 소유권 중심으로 정리 기능 내부 구조 기능마다 서로 다른 기준 presentation / application / domain / infrastructure 기준 Kafka / Redis / WebSocket 기술 중심으로 분산 사용하는 기능의 infrastructure 로 이동 Restaurant restaurant , sharedtable , timeslot 분리 Restaurant 소유 하위 기능으로 정리 Outbox 공통 처리와 기능 코드 혼재 공통 Core와 기능별 처리 분리 Security / Member 일부 책임 분산 auth , member 소유권 정리 DTO 역할 구분이 일정하지 않음 Request / Response / Command / Result / Model 외부 기술 경계 Reader / Verifier / Port / Adapter 혼재 Port / Adapter 기준 정리 생성자 주입 일부 수동 생성자 잔존 @RequiredArgsConstructor 기준 Lombok 사용 기준 불명확 허용 범위 명시 Logging 자유로운 메시지 형식 event=... 기준 주석 역할 설명과 작업 흔적 혼재 코드로 알 수 없는 WHY 중심 docs 현재 기준과 과거 기록 혼재 역할별 구조와 현재 기준 문서 정리 AI 작업 방식 작업마다 Context와 진행 방식 차이 Agent Workflow와 단계별 Context 기준 결국 이번 작업은 단순히 폴더를 옮기는 것에서 끝나지 않았다. 기능 소유권 ↓ 패키지 책임 ↓ 네이밍 ↓ 코드 작성 기준 ↓ 문서 기준 ↓ AI 작업 방식 까지 프로젝트를 다시 읽을 수 있는 기준을 정리했다. 2. 기존 동작은 유지했다 1차 리팩토링에서는 구조를 정리하면서 비즈니스 동작까지 같이 변경하지 않도록 범위를 제한했다. 유지한 영역 결과 API Mapping / HTTP 계약 유지 DB / JPA Mapping 유지 Transaction / Propagation 유지 Lock 유지 Kafka Topic / Consumer Group 유지 Outbox Event 계약 유지 Security / WebSocket 주요 동작 유지 최종적으로 전체 Build와 Test도 다시 수행했다. 검증 결과 Root Test 881 PASS / 64 SKIP / 0 FAIL Lambda Test 11 PASS / 0 FAIL clean build PASS Production Java package/path 402개 불일치 0 패키지와 코드 작성 방식은 크게 바뀌었지만 기존 동작을 변경하는 리팩토링은 이번 범위에서 분리했다. 3. 구조를 정리하니 다음 문제가 보였다 1차 리팩토링을 하면서 오히려 다음에 손봐야 할 부분이 더 명확하게 보였다. 남은 설계 부채 확인할 내용 도메인 간 직접 의존 다른 기능의 Repository / Entity 직접 참조 Application 의존 방향 Presentation DTO 직접 참조 Service 책임 Service / Facade / Domain Service 경계 Reservation / Payment / TimeSlot 기능 간 협력 방식 Reservation / Notification 직접 Service 의존 Admin Query Repository 의존 방향 Outbox 공통 Core와 도메인 계약의 결합 Event / Kafka 메시지 계약과 처리 책임 Transaction / Lock 실제 비즈니스 경계 재검토 AI 기능 전처리 / Rule / Provider 의존 방향 이 부분들은 패키지 위치를 바꾸는 것보다 실제 설계를 변경하는 작업에 가깝다. 따라서 1차 리팩토링에 같이 넣지 않고 2차 리팩토링 대상으로 분리했다. 4. 1차 리팩토링 종료 이번 단계의 범위는 여기까지로 정했다. 1차 리팩토링 패키지 구조 ↓ 기능 소유권 ↓ 네이밍 / 코드 작성 기준 ↓ 문서 정리 ↓ 전역 Audit ↓ 회귀 검증 ↓ 완료 처음부터 완벽한 구조를 만드는 것보다, 현재 구조를 같은 기준으로 정리하고, 그 과정에서 발견한 더 깊은 설계 문제는 다음 단계로 분리한다. 는 방식으로 진행했다. 이제 패키지 위치와 작성 기준을 정리하는 작업은 마무리했다. 다음부터는 이번 과정에서 기록해둔 설계 부채를 기준으로 도메인 간 의존성과 Service 책임부터 다시 확인해보려고 한다.

Детали предложения

Провайдер

velog

Источник

velog-rss

Балл

54.37

Уверенность