전시 동적필터 리팩토링: 정책과 생성 흐름 분리

동적 필터의 정의 및 기존 구조의 문제점

• 동적 필터: 사용자가 선택한 조건에 따라 이용 가능한 제휴점 수가 실시간 반영되는 필터.
• 기존 AS-IS 구조: 페이지 타입별 필터 노출/미노출 정책 결정.
  • 단순 조건: AnchorMapper 내 조건문 추가.
  • 복잡 조건: Creator 단계에서 페이지 타입 조건 처리.
  • 큰 정책 차이: Mapper 복사 및 페이지 전용 Mapper 생성.
• 문제점: 페이지별 정책 분산, Mapper 중복 존재, 변경/확장 어려움, 복제 중심의 구조 발전.

리팩토링 목표

1. 정책과 생성 흐름 분리: 변경 가능성 높은 노출 정책은 전략(Strategy)으로, 안정적인 생성 흐름은 공통 파이프라인으로.
2. 페이지 타입별 정책 구조화: enum 단위로 명시적 드러내기, 정책 변경 지점 명확화.
3. 확장 방식 개선: '복사' 대신 '조합' (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 내부 관리).
• 트레이드오프: 상대적으로 복잡해진 구조, 초기 진입 비용 증가.

결론

• 변경이 잦은 정책 영역과 안정적인 생성 영역을 구분하여 설계.
• 필터 정책 확장 시 구조적 복잡도 증가 방지 및 유지보수성 향상.