[리팩토링] 08. SwiftDataClient 리팩토링 - SwiftDataClient의 비대함 완화 및 명확한 구분

SwiftDataClient의 비대함과 구조화 필요성

와우.. 어지럽죠..

기존 SwiftDataClient는 모든 메소드가 한곳(SwiftDataClient 내부)에 구현되어 있어 가독성이 떨어지고, 코드가 너무 비대하다는 문제가 있었습니다.

---

무엇을 기준으로 분류할까

먼저, 전체적인 흐름 파악을 위해 각 피처에 어떤 메소드들이 사용되는지 정리해보았습니다. 

 

처음에는 단순히 리듀서별로 분류하는 방법도 고려했지만, 메소드가 한 개뿐이더라도 파일을 따로 생성하고 관리해야 한다는 점에서 과한 분리라는 생각이 들었습니다. 즉, 리듀서별 분리는 오히려 복잡한 구조를 만들 수 있다고 판단하여, 다른 기준을 고민해보았습니다.

 

그 다음으로는 기능 단위로 분류하는 방법을 고민했습니다. 예를 들어 CRUD 기준으로 나누어, 읽기 메소드만 모아서 관리하거나, 쓰기, 삭제 등 기능별로 묶는 방법입니다. 기능별 분류는 메소드의 역할이 명확하지만, 어떤 도메인 데이터를 다루는지가 한눈에 보이지 않아 코드 구조와 이해하기 어려울 것이다고 판단하여, 또 다른 기준을 고민해보았습니다.

 

결국 선택한 기준은 도메인 또는 엔티티 단위로 메소드를 분류하는 방식이었습니다. 결정의 가장 큰 이유는, 각 도메인별로 관련된 데이터 작업을 묶으면, 호출하는 쪽에서도 어떤 데이터를 다루는지 직관적으로 알 수 있다는 이유였습니다.

---

다이어트 시작

먼저, 도메인 단위로 메소드를 분류하여 각각의 Repository 파일로 분리하고, SwiftDataClient에서는 이를 통합하는 방식으로 리팩토링을 진행했습니다.

 

+ 여기서 말하는 Repository라는 이름은, 클린 아키텍처에서 이야기하는 엄격한 레이어 개념의 레포지토리를 의미하는 것은 아닙니다. 단순히 도메인별 데이터 접근 메소드를 묶는 단위 정도로 이해하면 됩니다.

 

즉, 이 구조를 통해 얻고자 한 것은 

1. 코드 가독성 향상

2. 도메인 단위의 명확한 구분

3. SwiftDataClient의 비대함 완화

정도이며, 아키텍처 레이어를 엄격하게 나누는 목적은 아니었습니다.

---

이랬었다가~

이렇게 됐어요!