-
질문 & 답변
카테고리
-
세부 분야
모바일 앱 개발
-
해결 여부
미해결
안녕하세요 선생님 아키텍쳐 관련해서 질문드릴것이있습니다.
23.02.19 23:22 작성 조회수 325
0
일단 선생님의 강의를 듣고 제 생각을 정의해보자면
데이터레이어(데이터소스, 레퍼지토리(구현))
도메인레이어(레퍼지토리(추상), 모델, 유스케이스)
프레젠트레이어(뷰 모델, 뷰)
레퍼지토리는 기본적으로 외부데이터와의 소통을 위한 통로라고 이해했습니다
그렇기 때문에
도메인레이어에서 레퍼지토리를 추상화하고
데이터레이어에서 이를 구현하는 방식으로 사용되고
이 레퍼지토리를 유스케이스에서
도메인레이어의 모델과, 레퍼지토리를 이용해
우리 도메인의 입맛에 맞는 데이터형식과 로직을 작성하지요
이런 상황속에서 몇가지 의문이 들었습니다
-첫번째질문!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!-
만약 외부데이터와 관련이 없는 온리 client 내부적으로만
필요한 상태를 관리해야하는 로직이 필요하다.
그렇다면
도메인 레이어에 필요한 모델을 작성하고
레포지토리없는 유스케이스를 만들면
외부데이터와 관련이 없는 상태를 관리할수있지 않을까?
=> 외부데이터와 관련없는 데이터 관리가 필요할경우
레포지토리가 없는 유스케이스에대한 생각이 궁금합니다!!
(레포지토리가 필요없는 유스케이스의 경우
쉽게 생각하면 viewModel에서 작성하면 되는 로직 아니야?
라고 생각할수있는데, 만약
해당 데이터 타입과 로직이 꽤많은 화면에서 공통적으로
사용되고있다면 모든 뷰에 대응하는 모든 뷰모델에서
같은 로직을 계속해서 반복하게될텐데
비효율적일것같아서
레포지토리 없는 유스케이스라는 것을 생각하게되었습니다.)
-두번째질문!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!-
비지니스로직은 유스케이스에
UI로직은 뷰모델에 작성한다고해주셨는데
비지니스 로직과 UI로직을 나누는 기준이 무엇인지 궁금합니다.
어떤걸 유스케이스에 넣고
어떤걸 뷰모델에 넣어야하는지에 대한
혼란이 있을때가 있어서요!!
-세번째질문!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!-
노트관련강의
30번째 강의의 두번째화면 UI작성 28분쯤
해당 색깔을 선택할때 배경색이 바뀌는 로직이
뷰에서 로직이 선언되어있는데,
뷰모델에서 해당 로직을 선언하지 않은 이유가 궁금합니다!
선생님의 강의 정말 잘 듣고있고
매번 너무 감사드립니다ㅜㅜ
질문 세가지 드렸는데,
글이 길지만 세가지 질문에 대한
답변 주시면 정말 감사하겠습니다ㅜㅜ
답변을 작성해보세요.
0
akanfldkdlel
질문자2023.02.20
빠른 답변 정말 감사드립니다!!!ㅜㅜ
첫번째 답변에 대한 추가적인 질문사항이있습니다!
-첫번째질문!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!-
=> 외부데이터와 관련없는 데이터 관리가 필요할경우
레포지토리가 없는 유스케이스에대한 생각이 궁금합니다!!
답변 => 네. 가능합니다. 다만 외부데이터와 관련없는 데이터 관리가 필요하다고 하셨는데, 결국 어떤 데이터를 관리하는 것이라면 레포지토리는 필요하지요. 레포지토리 없는 유즈케이스라면 어떠한 데이터와도 엮이지 않는 순수 로직만을 가지는 유즈케이스일 것이라고 생각합니다.
흠..일단
저는 레포지토리가 필요하지 않은 유스케이스라고 말한이유는
저희가 강의 진행 중 통상적으로 레포지토리를 사용할때
도메인 레이어의 레퍼지토리는 추상클래스로 작성되고
이에 대한 구현은 데이터 레이어에서 이루어졌기때문이었는데요!!!
선생님 말씀대로
결국 어떤 데이터를 관리하는 것이라면 레포지토리가 필요하다면
외부데이터와 관련없는 클라이언트 데이터와 로직이 필요할경우
도메인 레이어에서!!!!
필요한 모델 선언
필요한 레퍼지토리(추상클래스가 아닌 구현체!!) 선언
유스케이스에서 로직작성 하면될까요?
필요한 레퍼지토리(추상클래스가 아닌 구현체!!)
추상클래스가 아닌 구현체라고 표현한이유는
보통의 레퍼지토리의경우
도메인레이어에서 추상클래스로 작성되고
데이터레에어에서 구현되지만
외부데이터와 관련없는 로직의경우
굳이 도메인레이어에서 레퍼지토리를 작성할떄
추상클래스로 작성할 이유가 없다고 생각되어서요!!!
결과적으로
외부데이터와 관련없는 데이터와 로직을 작성할때
도메인 레이어에서!!!!
필요한 모델 선언
필요한 레퍼지토리(추상클래스가 아닌 실제 구현체!!) 선언
유스케이스에서 로직작성
위의 구조로 작성하면될까요?
0
오준석
지식공유자2023.02.19
강의를 정말 열심히 수강해 주신 것이 느껴집니다. 수준 높은 질문에 감사를 드립니다.
-첫번째질문!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!-
=> 외부데이터와 관련없는 데이터 관리가 필요할경우
레포지토리가 없는 유스케이스에대한 생각이 궁금합니다!!
답변 => 네. 가능합니다. 다만 외부데이터와 관련없는 데이터 관리가 필요하다고 하셨는데, 결국 어떤 데이터를 관리하는 것이라면 레포지토리는 필요하지요. 레포지토리 없는 유즈케이스라면 어떠한 데이터와도 엮이지 않는 순수 로직만을 가지는 유즈케이스일 것이라고 생각합니다.
-두번째질문!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!-
사용자의 액션에 해당하는 부분을 UI 로직이라고 표현하고 있습니다. 어떤 버튼을 클릭한다거나, 글을 입력한다거나 등등의 액션을 처리하는 직접적인 로직을 말합니다.
유즈케이스에는 데이터 조작에 대한 로직이 주로 들어간다고 보면 될 것 같습니다. 이런 조작들은 사용자의 액션과는 무관하게 동작되어야 합니다.
-세번째질문!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!-
뷰모델에서 해당 로직을 선언하지 않은 이유가 궁금합니다!
답변 => 뷰 모델로 옮기는 것이 좋습니다. 저의 실수입니다. 이를 수정하고 노트앱의 버그(디테일 화면의 ViewModel이 싱글턴이어서 색상이 리셋 안 되는 버그)도 수정한 코드가 gumsang_master 라는 브랜치에 올라가 있으니 참고하시기 바랍니다.
https://github.com/junsuk5/flutter-clean-architecture-course/tree/gumsang_master
이해되지 않는 것이 있다면 또 질문 주시기 바랍니다.
akanfldkdlel
질문자2023.02.20
빠른 답변 정말 감사드립니다!!!ㅜㅜ
첫번째 답변에 대한 추가적인 질문사항이있습니다!
-첫번째질문!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!-
=> 외부데이터와 관련없는 데이터 관리가 필요할경우
레포지토리가 없는 유스케이스에대한 생각이 궁금합니다!!
답변 => 네. 가능합니다. 다만 외부데이터와 관련없는 데이터 관리가 필요하다고 하셨는데, 결국 어떤 데이터를 관리하는 것이라면 레포지토리는 필요하지요. 레포지토리 없는 유즈케이스라면 어떠한 데이터와도 엮이지 않는 순수 로직만을 가지는 유즈케이스일 것이라고 생각합니다.
흠..일단
저는 레포지토리가 필요하지 않은 유스케이스라고 말한이유는
저희가 강의 진행 중 통상적으로 레포지토리를 사용할때
도메인 레이어의 레퍼지토리는 추상클래스로 작성되고
이에 대한 구현은 데이터 레이어에서 이루어졌기때문이었는데요!!!
선생님 말씀대로
결국 어떤 데이터를 관리하는 것이라면 레포지토리가 필요하다면
외부데이터와 관련없는 클라이언트 데이터와 로직이 필요할경우
도메인 레이어에서!!!!
필요한 모델 선언
필요한 레퍼지토리(추상클래스가 아닌 구현체!!) 선언
유스케이스에서 로직작성 하면될까요?
필요한 레퍼지토리(추상클래스가 아닌 구현체!!)
추상클래스가 아닌 구현체라고 표현한이유는
보통의 레퍼지토리의경우
도메인레이어에서 추상클래스로 작성되고
데이터레에어에서 구현되지만
외부데이터와 관련없는 로직의경우
굳이 도메인레이어에서 레퍼지토리를 작성할떄
추상클래스로 작성할 이유가 없다고 생각되어서요!!!
결과적으로
외부데이터와 관련없는 데이터와 로직을 작성할때
도메인 레이어에서!!!!
필요한 모델 선언
필요한 레퍼지토리(추상클래스가 아닌 실제 구현체!!) 선언
유스케이스에서 로직작성
위의 구조로 작성하면될까요?
akanfldkdlel
질문자2023.02.20
제가 말씀드리는 예시가 적절한지 모르겠으나,
외부데이터와 관련없는 클라이언트 데이터라함은....
이런앱이 있다고 가정해보겠습니다.
특정앱의 특정 몇몇의 화면에 들어가면
항상 어떠한 캐릭터, 아바타가 생성됩니다.
이 캐릭터는 DB에 남아있을필요도없고
휘발성으로 단순히 특정 화면에 나갔다 들어갈때마다
데이터가 초기화되고, 초기화된 아바타가 생성됩니다.
그럼 외부데이터와 관련이 없는 데이터라는것은자명한 사실입니다.
추가적으로
헌데 해당 휘발성의 아바타 타입을 여러화면에서
사용되기때문에
도메인레이어에서 관리하고싶습니다!!!
해당 휘발성의 아바타의 모델은
String name
int age
입니다.
특정화면에 들어갈때마다 해당 아바타는 생성되어야하며, 휘발성 State입니다.
그래서
화면 A에서는 해당 아바타의
name만 변경시킬수있고
화면 B에서는 해당 아바트의
age만 변경시킬수있습니다.
많이 축약되고 데이터나 로직자체가 예시상으론 간단하긴한데.....
약간 이런 상황이라면
외부데이터와 관련없는 클라이언트 데이터
이지 않을까 싶습니다!!
오준석
지식공유자2023.02.20
순수 메모리상의 데이터뿐이기 때문에 말씀하신 방법으로 문제 없을 것 같습니다. 유즈케이스의 테스트 코드를 작성할 때도 문제가 없을 것 같습니다. 단, 레포지토리는 도메인이 아니라 data 레이어에 두는 것이 일관적으로 관리하는 방법일 것 같습니다.
추가로 강의 주제에 맞도록 클린 아키텍처로 설계를 한다면
아바타를 제공하는 AvatarRepository 추상 클래스를 만들어서 AvatarRepositoryImpl 로 제공하는 것이 좋겠습니다.
이렇게 하면 아바타를 제공하는 로직이 수정되었을 때 Impl만 수정하면 됩니다. UseCase는 로직만 가지고 있기 때문에 아바타 생성 로직에 의존적이지 않게 되지요.
그리고 제공되는 아바타의 종류가 2개 이상으로 늘어났을 때에는 NormalAvatarRepositoryImpl 와 SuperAvatarRepositoryImpl 등의 여러개의 Impl 클래스가 생성되어 더 유연하게 활용될 수 있겠습니다.
akanfldkdlel
질문자2023.02.20
아바타를 제공하는 AvatarRepository 추상 클래스를 만들어서 AvatarRepositoryImpl 로 제공하는 것이 좋겠습니다.
라고해주셨는데 그렇게 된다면,
일반적으로
외부 데이터(데이터 소스)에 의존하는
RepositoryImpl 과는 다르게
저희가 예시로든
AvatarRepositoryImpl의 경우는
데이터 레이어의
데이터 소스(외부 데이터가아닌)에
의존하는 형태이겠지요??
늦은 시간까지 정말정말 감사드립니다ㅜㅜ
akanfldkdlel
질문자2023.02.20
데이터 레이어의
데이터 소스(외부 데이터가아닌!)에
의존하는 형태로 처리하면되는것이군요ㅜㅜ
의문이 해결되었습니다
정말 감사드립니다 선생님!!
답변 2