위드피스 아키텍처

[rhkrwngud445]

Clean Architecture, MVVM 사용 중인 우리 앱에서 어느 정도의 범위를 허용할 것인가? (엄격하게 지킬 것인지에 대한 논의)

[rhkrwngud445]

논의할 내용들

1. viewModel에서 domain을 참조할 때, usecase를 거쳐야 하는가?
2. view에서 domain model를 쓰는 것
3. view에서 viewModel로 응답값을 받을 때 observe 패턴을 무조건 써야 하는가?

[rhkrwngud445]

1. UI와 domain 인터렉션만 담당하는 것이면 꼭 거치지 않는 것이 어떨까? - 클린 아키텍처에 위배되긴 함
2. view-viewModel-domain 의존 방향에서 view가 이미 알 수 있는 정보에 대한 의존성을 추가하는 것, 도메인의 기능을 view에서 알 필요가 없다고 생각
   • nowInAndroid 처럼 Entity model을 두고 비즈니스 로직은 usecase에서 처리? -> 클린 아키텍처가 아님
   • uiModel -> 보일러 플레이트 코드가 많지만, 클린 아키텍처 및 원시값을 통한 데이터 접근 용이
3. 무조건 썼을 때 장점: view에서 observe 되는 데이터만 관리를 하면 된다.

[rhkrwngud445]

MV-Whatever 또는 android 권장 아키텍처 가이드를 따라간다면 해당 고민들은 해결될 것 같습니다.
저희가 지향하는 clean architecture에서는 참고할 정석적인 프로젝트가 없는 것으로 알고 있습니다.
여기서 아키텍처에 대한 관점 또한 다르다보니, 이로 인해 코드리뷰 비용도 많이 드는 문제점이 있습니다.
우리가 왜 아키텍처를 도입해야 하는지 명확히 한 후 아키텍처를 결정하면 좋을 것 같아요.

제가 생각한 아키텍처 기능을 정리드립니다.
dataModel(reseponse,request 등) - Data단의 직렬화 및 데이터를 간단히 전달 및 응답 받기 위한 DTO
datasource - 명확한 저장소에서 데이터를 가지고 온다.
repository - data에 접근하기 위한 저장소 local, remote 등 데이터를 가지고 온다. domain <-> dataModel 수행
domain - 비즈니스 모델, domain은 usecase를 통해서 접근 가능하다.
usecase - 비즈니스적인 사용자의 행동을 알 수 있다.
viewModel - usecase를 통해서 사용자의 행동을 수행, 데이터를 변경하여 view에게 이벤트를 전송한다. domain <-> uiModel 수행
view - 이벤트를 받아 화면을 갱신한다. 사용자 인터렉션을 viewModel에 알린다.
uimodel - UI단의 DTO, Parcelable 사용할 수 있고, UI 데이터를 간단히 뿌려주기 위함

저는 클린 아키텍처에서 위 사용성으로 생각하고 있었습니다. 클린 아키텍처도 선택적인 부분이기에, 좋은 방향이 있으면 말씀주세요!

[chws0508]

https://www.youtube.com/watch?v=3mR8_vT7m1U
저의 의견과 거의 일치해보여 영상남겨 봅니다.

아키첵텨의 정답은 없지만, 현재까지 제가 겪은 경험과 지금까지 작성한 코드에 기반한 제가 생각하는 최선을 말해봅니다.

비즈니스 로직 즉, 도메인 로직은 viewModel이 아닌, Domain 로직에 작성되야합니다.
DataModel의 필요성은 서버에서 정한 모델과 저희가 정한 모델의 불일치를 해결해주는 이점과, Serializable 이나 Entity등 안드로이드적 요소가 들어간 부분을 도메인 모델에서 사용하지 못하는 등, 확실한 이점과 불가피한 상황이 있기 떄문에 필요하다고 생각합니다.
하지만 UI Model의 필요성은 잘 모르겠습니다.
뷰에 표현되어야 하는 데이터는 결국 Domain 로직을 거쳐서 View에게 뿌려져야 합니다.
그런데, 모든 Domain 모델을 UiModel로 바꾸는 작업이 있고, 그 UI 모델이 Domain 모델을 가지고 있지 않다면, 아래 작업들이 필수로 선행되어야합니다.

1. 초기, 데이터를 뷰에 뿌려줄 때, Domain모델을 UiModel로 바꾸는 작업이 필요하다.
2. 사용자의 상호작용에 의해, 데이터가 변경된다면, UiModel을 다시 Domain 모델로 바꾸어줘야한다.
3. 바뀐 도메인 모델을 이용하여, Domain 모델 상태를 변경해야한다.
4. Domain 모델을 다시 UiModel로 변경하고 view에 뿌려준다.
   이러한 로직들이 viewModel에 필수로 포함되어야 하고, 이 외에도 UiModel 파일들이 무수히 많이 생성될 것입니다.
   그리고 이러한 UiModel을 재활용하는데에도 많은 어려움을 겪을 것으로 예상됩니다.
   따라서, 저는 도메인모델을 우리 화면에 이용되는 상태라고 생각하면 될 것 같습니다.
   이 상태를 view에서 이용한다고 생각하고, 상태에 따라 View가 표현되고, 비즈니스 로직은 이 상태모델이 캡슐화 하고 있다고 생각하면 어떨까요?
   그러면 Presentation Layer에서는 비즈니스 로직이 없다고 생각해도 되지 않을까요?
   그래서 결론은, Domain 모델을 View가 사용해도 괜찮고, 사용하지 않을 시 너무 많은 리소스가 든다가 저의 의견입니다.
   이것이 mvvm을 위배하는 거다 라고 생각하신다면, 저도 코비가 말했던것처럼 꼭 mvvm일 필요 없다는 생각입니다.
   필요에 따라 MVI 를 패턴을 사용하는 것도 상태관리에 용이할 것이라고 생각됩니다.
   물론 UiModel을 만듬으로서 UI로직에 관심사 분리가 되는 점이 장점이 될 수 있지만, 모든 모델에 있어서 만드는 것은 개인적으로 위에 말한 것 처럼 단점이 더 크다고 생각합니다. 정말 필요한 상황일 때 선택적으로 만드는 것이 좋다고 생각합니다.
   그리고 추가적으로, Parcelable로 사용하는 경우는 상당히 드물고, 만약 필요하다면, 다른 view로 넘길때 임시로 모델을 만들어 넘겨주면 된다는 생각입니다.

[rhkrwngud445]

저도 MV-Whatever 방식으로 하는 것이 현재 생산성에 도움이 된다고 생각합니다.
다만 이 부분에 대해서 스타일이 다른 것은 코드 리뷰시나 리팩토링시 감안을 해야하는 부분입니다.
동의하신다면 MV-Whatever 아키텍처 패턴으로 진행하면 될 것 같습니다.

또한 궁금한 점이 있는데, clean-architecture에서 Domain 영역 밖에 usecase가 있습니다. 이는 domain은 usecase를 거쳐야 합니다. 이는 어떻게 생각하실까요?!

결론적으로 화면에 대한 상태관리, MVVM,MVC 등의 아키텍처 패턴 등에 대한 코드는 현 구조에서 자유로 하고 정상적인 작동으로 이끄는지, 메모리 누수 측면에 대한 것에 리뷰를 진행하는 것은 어떨까요?!

[rhkrwngud445]

현재 정리

• 클린 아키텍처를 따르되 viewModel에서 usecase를 거치는 것은 필수적이지 않다.
• 고수준에서 저수준 모듈로 향한다.
• DataLayer은 DTO를 가지고 이를 통해 데이터를 transfer한다
  • serialzable Room의 Entity등의 사용성이 많기 때문에
• View-Model-Whatever 패턴 사용

[chws0508]

Presenter 영역에서 DomainModel(클아에서는 Entity로 명칭)를 이용하기 위해서 usecase를 꼭 거쳐야한다는 말씀인가요? 사진이 잘 안보여서 모르겠지만, 일단 저희 앱의 거의 모든 코드는 UseCase를 거쳐서 Domain 모델을 얻어오고 있을 것이라고 생각하고 왠만하면 Repository를 가지고있는 usecase를 통해 DomainModel을 얻어오는 것이 ssot 입장에서 좋아보입니다. 하지만 서버나 로컬에서 얻어오는 작업이 아니라서 Repository를 거칠 필요가 없거나, 이런거 까지 Usecase를 통해서 얻어와야되? 라는 생각이 드는 작업이라면 viewModel 에서 직접 Domain Model을 생성해도 된다는 생각입니다. 어차피 viewModel은 Domain Model을 알고 있으니까요.

[rhkrwngud445]

좋습니다 여기까지는 의견이 합치된 것 같아요!

결론적으로 화면에 대한 상태관리, MVVM,MVC 등의 아키텍처 패턴 등에 대한 코드는 현 구조에서 자유로 하고 정상적인 작동으로 이끄는지, 메모리 누수 측면에 대한 것에 리뷰를 진행하는 것은 어떨까요?!

위 의견에 대한 생각은 어떠실까요?! 아키텍처 패턴에 대한 부분은 각자 스타일대로 진행을 하는게 좋아보입니다!
의견이 갈렸던 "UI에서 도메인을 가질 수 있다", "Ui 상태는 원시값으로 가지고 있는다" 또한 아키텍처 패턴 영역이라 이 부분을 루즈하게 가져가는 것을 제안드립니다!

[chws0508]

아니요 저는 이 부분은 통일되야 한다고 생각합니다. 아무런 기준이 없이 어떠한 부분은 UI model로 변환하고 어떠한 부분은 그대로 Domain 모델을 사용하는 것은 코드의 통일성에 문제가 생겨 각자 코드를 건드릴 수 없을 것 같습니다. 그리고 계속 말했다시피 UI 영역에서 Domain 모델의 상태를 쓰는 것이 왜 잘못됐는지 잘 모르겠습니다. 사실 UI Model을 모두 변환한다는 의견을 아예 처음부터 제안했다면 저도 고려를 했겠지만 이미 수많은 코드가 Ui 에서 도메인 모델을 사용하도록 작성되었고, 이 많은 코드를 Ui Model로 변환하는 것이 시간적 대비 및 제가 위에서 말한 단점을 커버할 만한 장점이 있는지 잘 모르겠습니다. 만약 UI Model을 만든다면 만듬으로서 얻는 장점이 어떤것이고, 제가 위에 말한 단점을 커버할만한 장점이 있는지를 설득해주세요. 저는 UI 상태로서의 필요로 하지 않으면 (ex. 도메인 상태에 따른 testResourceId, drawableId) Domain 모델을 그대로 사용해도 된다고 생각합니다. 이미 많은 코드가 이렇게 작성되었고, 지금까지 문제가 없었습니다.

[rhkrwngud445]

저도 통일되는 것이 하나의 컨벤션으로 작용되어 유지보수를 용이하게 한다고 생각합니다. 다만 통일하려면 domain을 만들 때 상의가 되어야합니다. 저희는 아직 domain에 대한 기준이 아직 모호합니다.

1. Parcelable을 위한 UiModel이 생긴다면, ui screen에 domain model과 ui model이 혼용될 것입니다.
2. Ui 상태에 대한 변경이 domain에 영향을 미칩니다. 단순히 visible 상태를 관리하기 위해 Domain을 변경해야 할 것입니다. 이는 저수준의 모듈 변경을 위해 고수준 모듈을 변경하는 것입니다.
   • "visible 상태를 관리하기 위해 Domain을 변경" -> ex) 버튼을 클릭하였을 때 view가 보인다. - domain의 관심사일까요?!
3. doman 함수를 view에서 사용할 수 있습니다. 이는 비즈니스 로직을 수행하는 것인지, view위한 로직을 수행하는 것인지 직접 확인하여 판단해야합니다.
   • UiState를 통한 observer 패턴만 사용하면, UI는 viewModel의 UiState만 확인하면 됩니다. Ui에서 도메인이 사용되어서 Ui가 변경되는 것을 고려 안해도 됩니다.

위 단점을 UiModel 또는 원시값을 사용함으로서 해결할 수 있습니다.

유지보수적인 관점입니다. 하지만 이를 따르는 것이 클린 아키텍처에 위배되지 않는다고 생각합니다. case by case를 강화하여 문제점을 해결할 수는 있겠네요. 하지만 저희는 클린 아키텍처 경험이 많이 없으니, 원칙을 준수하는 것이 중요하다고 생각합니다.

[rhkrwngud445]

위 case by case를 강화하는 비용과 이에 소요되는 커뮤니케이션 비용이 uiModel을 만드는 것보다 크다고 생각되어서
자유로운 컨벤션 또는 엄격한 컨벤션 중에 선택을 제안드린 것입니다.

[rhkrwngud445]

domain은 비즈니스 규칙안에 있습니다.
그것에 대한 관점은 1차적으로 기획안에 따르고 2차적으로 개발자의 관점에 따릅니다.
"UI 상태가 비즈니스적으로 변경�이 없을 것이다." 이는 이전에 이야기 했던 "token 방식의 로그인은 변경 가능성이 적다"와 같은 맥락의 개발자 관점입니다.
개인적으로 domain은 서버가 하지 않는 domain 작업과 처리 그리고 UI와 Data를 유연하게 이어주는 것이 역할이라고 생각합니다. 바깥 원으로 추상화 시키는 비용이 있지만 외부 변경에서 유연해지는 점에서 UiModel이 존재 역할이라고 생각합니다.

빈약한 도메인과 유즈케이스가 UI와 Data를 유연하게 이어주는 역할이라고 볼 수 있겠네요.

[rhkrwngud445]

위 의견에 대한 생각은 어떠실까요?! 아키텍처 패턴에 대한 부분은 각자 스타일대로 진행을 하는게 좋아보입니다!
의견이 갈렸던 "UI에서 도메인을 가질 수 있다", "Ui 상태는 원시값으로 가지고 있는다" 또한 아키텍처 패턴 영역이라 이 부분을 루즈하게 가져가는 것을 제안드립니다!

위 의견을 드린 이유도 현재 커뮤니케이션 비용을 줄이고 case by case를 찾아가는 역할이 되지 않을까 생각이 됩니다.

[chws0508]

저도 통일되는 것이 하나의 컨벤션으로 작용되어 유지보수를 용이하게 한다고 생각합니다. 다만 통일하려면 domain을 만들 때 상의가 되어야합니다. 저희는 아직 domain에 대한 기준이 아직 모호합니다.

1. Parcelable을 위한 UiModel이 생긴다면, ui screen에 domain model과 ui model이 혼용될 것입니다.

2. Ui 상태에 대한 변경이 domain에 영향을 미칩니다. 단순히 visible 상태를 관리하기 위해 Domain을 변경해야 할 것입니다. 이는 저수준의 모듈 변경을 위해 고수준 모듈을 변경하는 것입니다.

   • "visible 상태를 관리하기 위해 Domain을 변경" -> ex) 버튼을 클릭하였을 때 view가 보인다. - domain의 관심사일까요?!

3. doman 함수를 view에서 사용할 수 있습니다. 이는 비즈니스 로직을 수행하는 것인지, view위한 로직을 수행하는 것인지 직접 확인하여 판단해야합니다.

   • UiState를 통한 observer 패턴만 사용하면, UI는 viewModel의 UiState만 확인하면 됩니다. Ui에서 도메인이 사용되어서 Ui가 변경되는 것을 고려 안해도 됩니다.

위 단점을 UiModel 또는 원시값을 사용함으로서 해결할 수 있습니다.

유지보수적인 관점입니다. 하지만 이를 따르는 것이 클린 아키텍처에 위배되지 않는다고 생각합니다. case by case를 강화하여 문제점을 해결할 수는 있겠네요. 하지만 저희는 클린 아키텍처 경험이 많이 없으니, 원칙을 준수하는 것이 중요하다고 생각합니다.

1. 이 의견은 동의합니다
2. Domain Model에 상태에 visible은 들어가지 않습니다. visible은 Ui요소이고, Domain 모델의 다른 상태에 따라 visible을 표현하면 됩니다. Domain 모델에 visible 속성은 없습니다. visible요소가 추가적으로 필요하다면, DomainModel을 포함하는 UiState를 만듬으로서 해결이 가능합니다.
3. 어차피 Domain을 Ui에서 바꾸어주는 과정에서 문제가 생길수도 있고, uiState만 바라보면 된다는 점에는 동의할 수 없습니다. 어차피 도메인에 문제가 있다면, Ui에도 문제가 생깁니다. 오히려 Domain을 사용하지 않으면 UiState로 바꾸어주는 Mapper 문제인지, Domain에 문제인지 더 헷갈리게 됩니다.

클린 아키텍쳐의 원칙에 정의에 대해서도 잘 모르곘습니다. 제가 생각하는 클린아키텍쳐는 고수준 모듈이 저수준 모듈을 참고하지만 않으면 되고, 관심사 분리만 잘 되있으면 클린아키텍쳐라고 생각합니다. 어떠한 정확한 원칙을 원하는지 잘 모르겠습니다.

만약 프로젝트 처음부터 이런 제안을 했다면, 코드를 작성하면서 도전해보고 겪어봤을 것 같지만, 지금은 엄청난 이득이 있지 않은 이상 제안해주신 구조를 따르기가 저는 힘들 것 같습니다. 그리고 이미 전 프로젝트에서 UiModel을 시도해보았다가 관리가 너무 힘든 것 같다는 생각에 다시 모델 한개만 쓰는 것으로 바꾸었던 경험이 있습니다.

[chws0508]

UiState는 View영역입니다

[rhkrwngud445]

이해가 잘 안 가는 것 같습니다.

버튼을 클릭하면, 다이어로그가 출력된다.

슈도코드로 흐름을 보여주실 수 있을까요?!

[chws0508]

버튼 클릭의 상태는 ComposeView에서 mutabeState변수를 선언하여 해결해도 되는 문제 같습니다.
제가 생각하는 것은 만약 RegisterPost의 도메인의 상태가 등록 불가 상태면, canRegister라는 getter valueable 변수를 이용하여 등록 버튼의 isEnabled에 적용해주기만 하면 됩니다. isEnabled = registerPost.canRegister

[rhkrwngud445]

클린된 상태가 구성변경에도 유지되어야 한다고 생각했을 때, viewModel이 상태를 가지고 있어야합니다.
이 로직이 UX적 변경 사안이라면 그 상태는 Domain이 관심사가 아닌 문제로 보입니다.

[chws0508]

canRegister는 비스니스적 요소고, canRegister를 뷰는 이용만 하는것입니다. Domain은 canRegister를 통해 버튼의 비활성화를 하는지, 버튼의 색상을 바꾸는지에 대한 관심은 없습니다.
그리고 구성변경에도 유지하는 것은 rememberSavable로도 가능해서 viewModel이 상태를 가지냐는 선택적 문제입니다.
이러한 간단한 상태는 Composeview에게 책임을 갖도록 하는것도 좋아보입니다.

[chws0508]

솔직히 말씀드리면, 제가 조금 어투가 강하게 나가는 이유도 왜 한달이 지난 지금 시점에서 이렇게 변경요소가 큰 이야기를 하느냐에 대해 조금 서운한 감정이 있었습니다. 죄송합니다. 저는 지금까지 제가 작성한 코드를 모두 바꿀 자신과 시간적 여유가 없습니다.

[rhkrwngud445]

저는 이제는 더이상 좁혀지지 않을 것 같다는 생각입니다.

위 의견에서

위 의견에 대한 생각은 어떠실까요?! 아키텍처 패턴에 대한 부분은 각자 스타일대로 진행을 하는게 좋아보입니다!
의견이 갈렸던 "UI에서 도메인을 가질 수 있다", "Ui 상태는 원시값으로 가지고 있는다" 또한 아키텍처 패턴 영역이라 이 부분을 루즈하게 가져가는 것을 제안드립니다!

다시 사이클이 돌아온 것 같습니다. 어떠실까요?!

[rhkrwngud445]

서로의 의견에 설득이 언되는 것이니, 이는 당장 중요한 문제가 아닐 수도 있을 것 같습니다.
유지보수 관점을 저와 스캇의 입장 2가지로 생각하고 리팩토링을 하면 그것 또한 규칙성이 되지 않을까요?!

[rhkrwngud445]

추후 MVI로 리팩토링하면서, 비교해보는 것도 좋은 경험일 것 같습니다.

[chws0508]

넵 그러면 UI 모델을 만드는 것은 자유로 두겠습니다. 두 코드를 비교해 보는것도 좋겠네요

[rhkrwngud445]

정리가 다 된 것 같습니다. 의견 주셔서 감사해요

• presentation layer에서 UiModel 사용 또는 domain model 사용은 자유
• MV-Whatever 적용 AAC ViewModel과는 별개의 적용
• domain은 무조건 usecase를 거칠 필요 없다.
• Clean-Architecture 적용, data layer는 같은 컨벤션을, presentation layer 컨벤션은 자유롭다.

이는 ADR로 기록되길 바랍니다. 추가적인 아키텍처 규칙에 대한 제안이 있다면 편하게 남겨주세요!
https://sungyong.medium.com/architecture-decision-records-adr-%EC%8B%A4%EB%AC%B4-%EC%A0%81%EC%9A%A9-45fc0dad090

또한 개인적인 의견으로 만약 아키텍처가 바뀌더라도 이미 완성된 코드를 같이 리팩토링 할 필요는 없다는 생각입니다. 여유가 없는 상황에서 잘 작동하는 레거시를 굳이 바꿀 필요는 없다는 생각입니다.