피드로 돌아가기
Dev.toBackend
원문 읽기
SRP 적용을 통한 변경 영향도 격리 및 I/O 분리 설계
SRP — Single Responsibility
AI 요약
Context
OrderService와 같이 다수의 관심사가 하나의 클래스에 응집된 구조로 인한 유지보수 효율 저하 발생. 비즈니스 로직, 데이터 저장, 알림 전송 등이 혼재되어 작은 변경이 시스템 전체의 Regression Risk를 높이는 구조적 한계 직면.
Technical Solution
- OrderService를 단순 Coordination Layer로 정의하여 각 도메인 로직을 전문 클래스로 위임하는 구조 설계
- Validation, Pricing, Repository, Notifier로 책임을 분리하여 변경 이유(Reason to change)를 단일화
- PricingService에서 I/O 의존성을 완전히 제거한 Pure Logic 구조를 채택하여 Unit Test 속도 향상
- Git Commit History 분석을 통해 빈번하게 동시 수정되는 코드 영역을 식별하여 책임 분리 경계 설정
- 과도한 분리로 인한 복잡성 증가를 방지하기 위해 '함께 변경되는 요소'를 하나의 그룹으로 묶는 응집도 최적화
실천 포인트
- 클래스 이름에 Manager, Helper, Util 등의 모호한 명칭이 포함되었는지 확인 - 단일 파일의 Git History에서 서로 다른 도메인의 수정 요청이 혼재하는지 검토 - 비즈니스 로직 테스트 시 DB나 외부 API Mocking이 과도하게 필요한지 분석 - 기능 변경 시 수정해야 할 파일 수가 급증한다면 과도한 분리(Over-engineering) 여부 판단