[장바구니 리팩토링 Homework: Layered Architecture] 라바(고제성) 과제 제출합니다.

[kojesung]

처음엔 "API 호출 방식이 변경되는 모든 경우에 대응"하기 위해 Repository 패턴을 선택했습니다. 하지만 리팩토링 결과를 보니 오히려 React 생태계에서 흔히 쓰는 apiInstance 방식보다 변화에 대응하기 어려워 보이는 부분이 있었습니다.(fetch -> axios로 변경되면 모든 엔드포인트별로 메서드를 다시 만들어줘야 했음)

fetch -> axios와 같은 변경 형태와 처음 리팩토링한 Repository 패턴이 대응할 수 있는 변경 형태가 다루는 변경 관점이 다르다는 걸 인지하지 못했기 때문에 발생한 시행착오였다고 생각합니다

• fetch -> axios (HTTP 클라이언트 교체): apiInstance / HttpClient 인터페이스
• HTTP -> InMemory (저장소 구현 교체): Repository 인터페이스

fetch -> axios와 같은 형태의 교체는 HTTP라는 전제가 깔려있는 상태인데 Repository가 이 기준점까지 담당하게 된다면 AxiosProductRepository와 같은 구현을 별도로 작성해야 하고 도메인 메서드를 통째로 다시 구현하게 됩니다.

이에 대한 해결 방법으로
HttpClient 인터페이스를 한 계층을 추가하여 분리했습니다.

HttpClient
 └─ FetchHttpClient
 └─ AxiosHttpClient

ProductRepository
 └─ HttpProductRepository(http: HttpClient)
 └─ InMemoryProductRepository 

• FetchHttp Client: fetch 구현
• AxiosHttpClient: axios 구현

---

• HttpProductRepository: 주입받은 HTTP 클라이언트 기반 엔드포인트 매핑
• InMemoryProductRepository: ...
• ..

결과적으로 HttpClient 인터페이스가 apiInstance와 동일한 효과를 내면서, Repository 패턴의 본래 역할이었던 저장소 구현 교체도 함께 커버하는 구조가 되는 것을 의도했습니다.