의존성 주입으로 DB를 바꿔보자
OaO의 근본은 Todo 앱! 이를 위해서 Todo 데이터를 관리하는 시스템을 개발해야 했는데, 현재까지의 상황은 아래와 같았다!
-
어떤 DB를 써야할지 정해지지 않은 상황
- 멘토님의 조언에 따라 일단 FE에 집중하여 구현을 진행하기로 했다.
- FE에 집중하여 구현을 진행하기 위해, 우선 데이터는 로컬에 저장하는 방향으로 진행하기로 했다.
- 일단 로컬에 저장하는 것일 뿐, 언제든 서버 DB와의 연동이 가능하게끔 계획 중이다! 또, 서비스 특성상 팀원들 중 아무도 사용해보지 않은 graphDB를 도입해야 할 수도 있다!
-
Todo 데이터 관리 시스템 인터페이스를 먼저 정의함
- 팀원 모두가 FE 개발에 집중하고, 2명은 컴포넌트 구현에, 2명은 Todo 데이터 관리 시스템 구현에 투입되었다.
- 원활한 병렬작업을 위해서 Todo 데이터 관리시스템(TodoList API)의 인터페이스를 먼저 확실하게 정의하고 구현을 시작해서 컴포넌트 팀이 TodoList API의 내부 로직 구현 정도에 독립적으로 구현을 진행할 수 있게끔 했다!
- DB를 어디에 구축하든, DB와의 상호작용은 비동기적으로 하는 것이 더 유연한 구현을 가능하게 할 것이라 판단해서 모든 데이터 관리 로직(CRUD 로직)을 비동기 인터페이스로 미리 정의했다.
-
일단은 메모리를 사용하도록 TodoList API 구현체 개발
- API 정의가 되어 있으니, 내부 구조는 어떻게 되든 상관이 없다고 판단했다!
- 알고리즘이 복잡하고, 순수성 등 고려할 점이 많다고 생각해서 일단 별도의 DB 연결 없이 메모리에서 모든 로직이 돌아가게끔 TodoList API의 구현체를 개발했다.
- 구현 후, 메모리에서 동작하는 로직만으로 컴포넌트 팀의 설계와 잘 융합되어 동작하는 것을 확인했다.
일단 메모리를 사용하는 TodoList API는 온전하게 잘 동작하는 것을 확인했으니, 이제 실제 확장, 아니 적어도 확장성을 고려한 형태로 구조를 변경해야할 차례가 왔다.
현재의 구조는 모든 데이터 관리가 TodoList 클래스에서 일어나는데, 일반적으로 DB가 수행하는 업무만을 별도의 인터페이스로 정의하고 분리해서,나중에 DB의 종류를 바꾸거나 서로 다른 DB를 사용하고 싶을 때 의존성 주입 형태로 DB를 바꾸어가며 사용할 수 있도록 구현하기로 했다!
- TodoList 인터페이스 전체를 DB로 이관하기
- TodoList 전체를 읽어들이는 행동의 로드가 크므로, 일종의 캐시를 남기도록 함.
- 앱이 켜질 때 TodoList 초기화 하며 DB와 동기화
- 이후로는 Read 요청은 TodoList에서만 핸들링 하며, 메모리에서 바로 참조.
- CUD 요청은 DB로 보내며, DB에서 완료 응답이 오면 DB에서 전체 리스트를 읽어들여 TodoList와 동기화