Clean Architecture 파묘요~!
서론
이번 프로젝트에서 로그인 기능을 구현하면서, Clean Architecture의 장단점에 대해 고민해보고 JWT를 적용해보았다. 적용을 하며 토론을 해보고 난 후 클린 아키텍처의 감상을 기록해보려 한다.
우리는 클린 아키텍처를 왜 적용하는가?
우리 안드로이드 팀원들은 domain layer, repository pattern 등의 필요성을 같이 알고 있었다. (안드로이드 권장 아키텍처) 이는 Testable, 유지보수의 편의성으로 이어진다.
여기서 usecase 등의 개념을 학습하고, Domain Layer의 확실한 분리를 목적으로, 큰 목표로는 아래 요소들을 지키기 위해 시작했다.
- UseCase만 보아도, 이 시스템에 기능을 파악할 수 있어야 한다.
- UseCase는 최대한 세부 구현(하위 모듈)의 변경에 영향을 받지 말아야 한다.
- 관심사 분리가 확실히 되어야 한다.
ViewModel 로직과 Domain 로직의 기준은 아래로 구성했다.
도메인 로직은 회사(팀)에서 모바일 개발자가 아닌 직원들도 알아야할 내용이다.
고민이 된 상황들
JWT를 적용을 하면서, 클린 아키텍처 문제와 맞닥뜨리게 되었다. 2가지 문제가 있었는데
- Interceptor에서 로직 처리
- TokenRepository의 사용성
Interceptor에서 로직 처리
Refersh Token을 통해 Access Token을 발급받는 로직을 자동화 하기 위해, Interceptor를 썼다.
우리에 요구사항에는 "Refresh Token이 만료되면 로그인 화면으로 돌아간다"가 있었는데 Interceptor에서 자동화를 하면 UI 코드를 끌어다 써야하는 문제점이 있었다.(의존성 방향이 단방향이지 않게 된다)
해결방안 리스트
- 그래도 그냥 한다.
- UI단으로 방출한다.
그냥 Interceptor에서 처리해버리면, UI 관련 요구사항이 늘어날 때, 관리가 어려운 단점이 있었다. 그래서 Refresh 만료시 그대로 방출하기로 결정했고 이를 BaseViewModel을 통해 모든 필요한 모든 ViewModel에서 위 처리를 하기로 하였다.
TokenRepository의 사용성
문제의 발단은 프로젝트 시작 후 가장먼저 자동로그인을 위한 로직을 구상할 때였다.
이 때 IsLoginUseCase를 만들고 Token 도메인 모델을 통해 token이 있는지 도메인에서 검증을 하였다. 나중에 login과 signUp을 만들고나니 TokenRepository에서 login, signUp을 하고 token 데이터를DataSource부터 불러와서 가지고 있는 형태였다.
TokenRepository에 대해 어색함을 느끼고, 너무 많은 역할을 한다고 생각했다. 그래서 사용성에 대한 변경을 제안하였다.
- AuthRepository로 변경 (범용적인 의미를 담고있음)
- accessToken 존재에 대한 검증을 분리 또는 추상화하자
위에 대해서 의견을 나누었는데, 의견이 분분했다.
나의 의견:
Token은 데이터영역이다. 로그인 방식에 따라 변경 될 수있다. 비즈니스 관심사는 로그인 유무를 가져오는 것이다. AuthRepository라는 RestAPI의 리소스명을 사용하자
팀원의 의견:
Token을 검증하는 방식은 비즈니스 관심사이다. 변경 가능성이 적다. 또한 TokenRepository는 Token이라는 데이터를 다루기위한 저장소이다.
결론
결론적으로 TokenRepository라는 팀원의 의견을, 처리 로직은 나의 의견을 따라가기로 하였다.
거의 10시간 가까이 게더와 깃헙의 디스커션을 통해 토론하였다. 왜 이렇게 토론이 길어질까 생각해봤는데, Domain이 모호했고, 클린아키텍처는 규칙과 융통성 그 사이에서 저울질을 하더라
- 추상화는 확장성이 좋다. 그럼 다 추상화를 해버리면 확장성이 좋은거 아닌가?
- 틀린말은 아니라고 생각한다. 하지만 대비의 비용이 너무 크지 않은가?
- 그러면 어떻게 결정하는가? 같이 우테코를 했던 크루의 글을 첨부한다.
---- 아래는 제 개인적인 의견입니다 ----
그래서 Domain은 뭔데?
Mobile에서 Domain은 애매하게 다가왔다. 비즈니스 요구사항은 대부분 서버에서 이루어지지 않는가?
- 아닐 수도 있지만 내가 CEO라면 서버보다 안드로이드 로직을 수정하게 할 것 같다. 서버가 견고하면 여러 플랫폼에서 쓸 수 있기 때문이다.
그러면 우리 Frontend(Android) 도메인은 뭔데!
나도 아직 모르겠다. UI(UX) 영역과 Data(Backend DB)의 원활한 협력을 위한 무언가가 아닐까..?
그래서 이제부터 도메인은 팀원들과 긴밀히 상의해서 만드려고 한다. 어떻게 쓰일지 예측의 영역이기 때문에
내 감상
Clean Architecture 잘못 이해하면 무덤이 맞다. 다 지킬필요 없다 비용을 고려해서 팀원들과 합의를 하고 진행할 것
