TokenRepository 변경에 대한 제안

[rhkrwngud445]

TokenRepository의 사용성에 대해 변경제안 드립니다.

• Repository의 패턴은 데이터 출처와 관계 없이 동일 인터페이스로 데이터에 접속할 수 있도록 만드는 것입니다.
  • login을 API를 통해서 하는 것과 Token을 통해서 하는 것을 같은 인터페이스로 하는 것에 의미가 있다고 생각합니다.
  • TokenRepository에서 getAccessToken 또한 목적은 로그인 유무를 가져오는데에 있다고 생각합니다. -> AuthRepository.isLogin()

이전 프로젝트에서 같은 고민을 했었는데, DataSource를 활용해서 아래와 같이 해결하였습니다.
repository
datasource

[chws0508]

Repository는 데이터를 엑세스하는 요소로만 사용되야 한다고 생각합니다. Token을 가져오는 행위가 로그인 유무를 가져오는 것이라고 판단하는 것은 비즈니스 로직이라고 생각해요.
따라서, 저희가 이미 구현한것 처럼, IsLoginUsecase에서 Token Repository를 통헤 데이터를 엑세스 하고 그 데이터를 토대로 Login의 유무를 판단하는 것이 더 나은 아키텍쳐라고 생각해요.
https://engineer-mole.tistory.com/345

[rhkrwngud445]

저는 로그인 유무를 가져오는 것만 비즈니스 로직이라고 생각합니다.
그 로그인 유무는 repository를 통해서 어떤 방식이든 (내부 토큰, API, SDK 등) 가져오는 것이 역할이라고 생각합니다.
또한 로그인 유무를 가져오는 방식이 변경 되었을 때, TokenRepository의 이름과 역할도 변경이 될 것 같습니다. TokenRepository에서 다른 레포지토리를 만들어 갈아끼울 수도 있지만, 이는 도메인(usecase)에 변경이 일어나는 것이 아닐까요?
AuthRepository로 인증의 범위를 관리한는 건 어떨까요?!

[rhkrwngud445]

3. 이 사안은 클린아키텍처에 해당된다고 생각합니다. 저희가 미래를 예측할 수 없습니다. "다른 걸로 쓰이진 않을까"가 아닌 예측 불가능한 영역을 대비하는 것에 의미가 있으므로, 클린 아키텍처라고 생각합니다. 저도 Token이 불변 방식이라고 장담은 못내립니다.

• 야그니 원칙은 추가적인 기능을 대비하기 위함에 있습니다. ex) 게시글 수정할 떄 이미지 기능도 같이 수정할 수 있을 것이다. -> 이미지 수정 기능 만든다

[rhkrwngud445]

2. Auth 도메인은 어떤 역할을 할까요? tokenPreference에서 토큰이 있는지 여부를 하는게 맞다고 생각이 됩니다.

[chws0508]

1. Repository를 Restful api의 식별자로 둔다고 하는 것은 결국 domain Model의 자원을 식별자로 두는 것이 Rest ful 하지 않을까요? 저의 의견과 동일한 것 같은데요? 또한 앞서 말했듯이 가장 중요한 문제가 Repository의 책임 분할 및 네이밍 문제입니다. 항상 어떻게 네이밍 지어야할지 고민해야 하고, 어디에 책임을 둬야할지 고민하게 되면 비용이 커질 거 같아요. 단순하게 한 Repository가 특정한 Domain 모델 관련 데이터를 주는 책임으로 Repository 네이밍과 책임을 분할하는 것이 개인적으로 앞으로 유지보수 측면에서 좋아보입니다.
2. 변할 확률이 정말 낮은 거를 "현재" 대비하는 것은 같은 야그니와 같은 맥락이니 비용적 측면이 발생하지 않을까요? 만약 Auth로 바꿀 필요 없이 Token이 네이밍이 더 명확하지만, 미래를 위해 Auth로 바꿔서 가독성을 해치는 것은 비용적 측면이 발생한다고 생각해요. 트레이드 오프 영역이긴 하지만, 변할 확률이 극히 낮은 문제로 인해 현재 비용이 발생하는 것은 생각해 봐야할 것 같아요.
   결국 저의 의견은 Token과 TokenRepository 그대로 두어도 되고, Token이라는 네이밍이 인증 관련 내용을 포함하고 있다고 보기에 애매하거나 Auth라는 네이밍이 더 가독성 측면이나 추후 유지보수 측면에서 좋다고 생각하면 Auth 도메인과 AuthRepository를 둬도 괜찮다는 의견입니다.

[rhkrwngud445]

1. 저의 의견은 조금 다릅니다. Auth,Token 외의 Domain Model의 예시를 들어주실 수 있을까요?
2. 구조적인 확장성을 위한 수정도 야그니 원칙일까요? 저는 미래상황을 예측할 수 없다고 생각합니다.

• 저는 AuthRepository -> AuthLocalDataSource 통해서 가져오는 것이 좋다고 생각합니다.

[rhkrwngud445]

유저 정보에서 최근 쓴 게시글 리스트를 볼 때, 보고 있는 게시글의 유저 정보를 확인할 때 어떻게 도메인으로 구분할 수 있을까요?
데이터 엔티티(서버의 Response,Request 등)는 여러 도메인의 협력이 아닐까요?
게시글의 상세보기와 미리보기의 내용이 다를 때는 어떻게 할까요? ThumbnailPostRepository, PostRepository가 따로 존재할까요?

[chws0508]

1. 저의 의견은 조금 다릅니다. Auth,Token 외의 Domain Model의 예시를 들어주실 수 있을까요?
2. 구조적인 확장성을 위한 수정도 야그니 원칙일까요? 저는 미래상황을 예측할 수 없다고 생각합니다.

• 저는 AuthRepository -> AuthLocalDataSource 통해서 가져오는 것이 좋다고 생각합니다.

1. 지금 떠오르는건 Poster, User, Order 등이 있겠네요. 저희가 지금 의견이 좁혀지지 않는게 안드로이드 영역에서 도메인 이라는 영역이 정말 애매해서 그런 것 같아요.
2. 이 부분은 결국 트레이드 오프 영역이고 개발자마다 생각하는 정답이 다를것입니다. 아까도 말했듯이 구조적인 확장성을 대비하는 것을 물론 찬성하지만 이로인해 당장 문제가 생긴다면 모든 것을 고려하여 어느것이 더 이득일지 생각하고 판단할 것 같아요.

-> 도메인 모델명은 Token으로 유지하면서, AuthRepository AuthLocalDatasource 이렇게 변경한다는 얘기인가요? |

[chws0508]

유저 정보에서 최근 쓴 게시글 리스트를 볼 때, 보고 있는 게시글의 유저 정보를 확인할 때 어떻게 도메인으로 구분할 수 있을까요? 데이터 엔티티(서버의 Response,Request 등)는 여러 도메인의 협력이 아닐까요? 게시글의 상세보기와 미리보기의 내용이 다를 때는 어떻게 할까요? ThumbnailPostRepository, PostRepository가 따로 존재할까요?

유저는 UserRepository를 통해 가져오고, Poster 부분의 경우에는 논의를 해봐야 할 것 같네요. 저라면 Poster객체가 PosterThumbNail을 포함하는 영역이라면 하나의 Poster 객체로 두고 관리할 것 같아요.Repository는 PosterRepository로 생성하구요. 그것을 어떻게 보여줄지는 화면의 책임이구요. 지금 생각해보니 저희의 Domain Model(클아 에서는 Entitiy라고 명칭)을 정하는 규칙이나 나름의 정의가 필요한 것 같네요. 근데 너무 애매해서 사실 정하기 너무 어려운 것 같아요. 특히 안드로이드는 도메인의 역할이 많이 필요 없다고 여겨지니 더더욱 그런 것 같구요.

[rhkrwngud445]

동감합니다 트레이드 오프영역이에요 Domain Model을 포함한 Domain Layer은 일관적으로 규칙을 정할 수 있는 영역이 아닌 것 같아요. 구현시에 이야기를 지속적으로 해야하는 영역으로 보입니다.
이번 Token 또한 같은 맥락으로 논의가 길어진 것 같아요.
Token에 대한 제안은 다음과 같습니다.

• LocalDataSource 만든다 -> 토큰 보유 여부에 따라 Boolean을 반환하는 메소드
• AuthRepository에서 토큰을 저장�하는 로직은 DataSource로 이동. -> AuthRepository.saveAuth()
• accessToken, refreshToken을 레포지토리 필드에서 제거
• 이렇게 되면 Token이 도메인에서 가지고 있지 않아도 된다.

장점

• repository 필드가 깔끔해진다.
• 앱에서 가지고 있는 token에 대해 datasource가 책임을 진다. (관리 용이)
• Auth를 통해 인증에 대한 것을 관리한다.
• 만약에 변경이 된다면 수정에 용이

[rhkrwngud445]

글을 쓸 때 로그인 여부를 확인한다. -> repository에서 datasource로 접근을 하면 될 것 같아요. 정말 token에 대한 관심사만 다룰 수 있어 사용성이 좋아질 것 같습니다!

[chws0508]

LocalDataSource 만든다 -> 토큰 보유 여부에 따라 Boolean을 반환하는 메소드
-> 이건 Repository에서 하는게 나아보여요. Repository의 목적이 같은 종류의 데이터를 한곳에서 관리하겠다 이므로, 데이터를 가공하는 역할은 Repository에서 하는게 좋아보여요.
-> 그리고 이미 DataSource가 있지 않나요...? 현재 LocalDataSource가 PreferenceDataSource라고 명시하고 있는데, DataSource는 어디에서 출처된 데이터인지 명확하게 명시하는 것이 좋아보여서 PreferenceDataSource라고 해도 될것 같아요.

단순하게 책임을 정의하면 이렇게 하는것을 일단은 이렇게 하는것을 제안해보아요.
Datasource -> DataModel을 단순 CRUD할 수 있는 곳
Repository -> 여러 Datasource에서 온 데이터를 가공해서 Usecase에게 전달함. -> 최대한 가공하여 전달.
Usecase -> Repository에서 가공된 데이터(Domain Model)들을 이용하여(여러 Repository또는 UseCase를 사용) 비즈니스 로직을 수행한다.

• Repository가 깔끔해진다 -> 이것은 저희가 사용하지 않는 필드값을 사용하고 있어서 그런 것 같아요. 필드값 지우는건 동의합니다. Repository에는 사용하는 로직만 노출하는 것에 동의합니다. 모든 DataSource로직이 있을필요가 없죠.
• Auth를 통해 인증에 대한 것을 관리한다. -> 이부분이 애매한 것 같네요. 저는 Repository는 자원을 관리하는 용도로 쓰는 것 외에 역할이 들어가버리니 애매한 것 같아요. 사실 제 개인적인 생각은 이 부분도 토큰을 전달하고, 서바가 토큰을 이용해 인증을 하니 TokenRepository로 짓는것도 좋아보입니다. 그런데 동의하지 않는다면 이 부분은 애매한 상황이니 AuthRepository로 타협하겠습니다.

사실 저는 Repository의 명칭을 자원중심으로 지었으면 합니다. 제가 생각하는 Repository패턴의 핵심은 결국 데이터가 로컬에서 오든지 서버에서 오는지 상관없이 한곳에서 관리하는 것이라고 생각하니까요. 자원이 바뀌면 자원의 명칭이 바뀌는 것은 피할 수 없다고 생각해요.

[chws0508]

PostUsecase를 만든다.

PostPosterUseCase(
isLoginUseCase:IsLoginUseCase,
 posterRepository:PosterRepository
){
fun invoke(){
   if(isLoginUseCase()){
posterRepository.post()
}else{
blabla
}
}
}

[rhkrwngud445]

위 정리된 내용에 저도 동의합니다. 인증을 하는 것이 자원에 입장에 있어서 Token 데이터가 움직이는 것으로 볼 수 있으니 또한 동의합니다!
또한 사용성에 대해서 제가 원하는 방�향이 반영된 것 같아 찬성입니다!