기존의 구조는

presentation → data

단방향으로 UI 단에서 data 계층을 참조한다.

앱잼이라는 기간 내에 domain 계층을 거치는 불필요한 과정의 최소화

usecase 사용의 불확실성

domain 계층에 대한 정리에 대한 내용을 근거로 들 수 있는데

의존 이라는 단어를 잘 생각해 보아야 하겠다.

presentation 에서 API 를 호출할 때는

viewmodel → repository → repositoryimpl → datasourceimpl → datasource → service → dto 로

서버에서 받아온 데이터를 datasource 를 거치고 repository 쪽에서 model 의 확장함수를 통해서 변환을 시키는데 이렇게 되면 변환된 data구조( 원래는 mapper 를 통해서 변환하겠지만) 를

ui 단 에서는 state 로 선언한 형식으로 viewmodel 에서 stateflow 를 통해 사용하면 된다.

그렇게 된다면 presentation 단에서는 dto 형식에 대한 수정 x, 의존할 필요가 없으니까

그렇게

이런식으로 feature 당

remote 쪽에서 처리하고

DI 를 각 feature 별로 나누기 떄문에 하나의 feature 당

data layor 에서만 의존을 하면 되기 때문에 상관이 없다,

문제는 Optional 한 Domain 계층을 추가할 때 고민이 되는 것이다.

기본적인 구조는

presentation -> domain -> data

해당 계층을 거치면서

domain 에는 repository, entity, mapper, usecase 를 사용하는 것으로 알고 있다.