핵심요약
여기어때 전시개발팀은 동적 필터의 AS-IS 구조가 페이지 타입별 정책 분산과 복제 중심의 확장에 어려움을 겪자, 이를 리팩토링했습니다. 정책과 생성 흐름을 분리하고, 페이지별 정책을 enum 기반의 전략 패턴으로 구조화하여 확장성과 유지보수성을 개선했습니다.
전시 동적필터 리팩토링: 정책과 생성 흐름 분리
동적 필터의 정의 및 기존 구조의 문제점
- 동적 필터: 사용자가 선택한 조건에 따라 이용 가능한 제휴점 수가 실시간 반영되는 필터.
- 기존 AS-IS 구조: 페이지 타입별 필터 노출/미노출 정책 결정.
- 단순 조건: AnchorMapper 내 조건문 추가.
- 복잡 조건: Creator 단계에서 페이지 타입 조건 처리.
- 큰 정책 차이: Mapper 복사 및 페이지 전용 Mapper 생성.
- 문제점: 페이지별 정책 분산, Mapper 중복 존재, 변경/확장 어려움, 복제 중심의 구조 발전.
리팩토링 목표
- 정책과 생성 흐름 분리: 변경 가능성 높은 노출 정책은 전략(Strategy)으로, 안정적인 생성 흐름은 공통 파이프라인으로.
- 페이지 타입별 정책 구조화: enum 단위로 명시적 드러내기, 정책 변경 지점 명확화.
- 확장 방식 개선: '복사' 대신 '조합' (Predicate 조합)으로 해결.
개선된 TO-BE 구조
- 핵심: 페이지 타입별 정책은
QuickFilterStrategy에서, 필터 생성은QuickFilterBuilder가 담당.
1. QuickFilterStrategy (전략 패턴)
- 페이지 타입별 필터 노출 정책을 enum으로 정의.
- 각 전략은 모텔/비모텔/게스트하우스별 할인 필터 조건, 카테고리 필터 포함 여부 등 결정.
- Service 레이어 및 Builder의 분기 로직 제거.
2. QuickFilterBuilder (생성 흐름)
QuickFilterStrategy의 결정에 따라 필터 생성 로직 실행.- Anchor 생성, Content 조립, 결과 리스트 구성 등은 Builder와 Mapper 책임.
- 카테고리 조합에 따른 정책 분기 캡슐화.
AS-IS vs TO-BE 비교
AS-IS
- 장점: 초기 구현 비용 낮음, 카테고리 중심 요구사항 빠른 반영.
- 한계: 페이지 타입 정책 분산, 생성 로직 변경 가능성, 확장 취약.
TO-BE
- 장점: 정책과 생성 흐름 분리, 구조적 확장 용이 (Predicate 조합), 변경 용이성 (전략 enum 내부 관리).
- 트레이드오프: 상대적으로 복잡해진 구조, 초기 진입 비용 증가.
결론
- 변경이 잦은 정책 영역과 안정적인 생성 영역을 구분하여 설계.
- 필터 정책 확장 시 구조적 복잡도 증가 방지 및 유지보수성 향상.
여기어때
