[refactor/#86] 도메인 계층 추가

[vvan2]

ISSUE

• closed [refactor] Domain 계층 추가 #86

❗ WORK DESCRIPTION

• 불필요한 파일 제거 : Dummy용 파일, Demo 데이터용 파일
• data layer 패키징 수정 : parent 에서 사용되는 파일이 kid와 다르게 feature 별로만 구분되어 있어서 parent 내부로 경로 변경했습니다.
• domain layer 추가 : useCase 추가

📢 TO REVIEWERS

• Domain 계층 추가하면서 기존 파일들 패키지 수정 위주로 진행하였습니다.

• Data layer 파일 통일성을 위해서 경로를 수정하였습니다.

• Core/DesignSystem 쪽 component 들을 확장성을 위해 컴포넌트 단위로 패키징할지 고민중입니다.

• Domain 계층에 repository, entity 가 들어가야 되나 고민하다가 useCase 만을 추가했습니다.

• 이유는 따로 노션에 정리했습니다. 궁금하시면 순서대로 읽어주세요
  https://www.notion.so/2beab2edd62880409404d8c6b2dfbfeb?source=copy_link
  https://www.notion.so/Domain-308ab2edd628804b9b8de27231bbd480?source=copy_link

• 아직 domain 쪽에 useCase가 없지만 내용 확인하시고 필요시 의도에 맞게 useCase 추가해주시면 됩니다.

• Ds 수정된거랑 아이콘 추가해줄 분 구함... 키하하

• 파일 체인지가 많은데.. 옮기고 지우고 하면서 의존성 확인해보느라.. 그냥 경로만 수정된게 대부분일 겁니다.

📸 SCREENSHOT

com.kiero
├── KieroApplication
├── core/
│   ├── common
|   |   ├── base/ provider base
│   │   ├── extension/ Kotlin 확장 함수
│   │   ├── util/ 공통 유틸 함수
│   │   └── viewmodel/ viewmodel 확장 함        
│   ├── designsystem
│   │   ├── component/ 공통 UI 컴포넌트
│   │   └── theme/ 디자인 시스템 (Color, Typography 등)
│   │
│   ├── localstorage
│   │   ├── constant/ DataStore Key 등 상수 정의
│   │   ├── di/       LocalStorage DI 모듈
│   │   ├── info/     로컬 저장 정보 관련 모델
│   │   ├── onboarding/  온보딩 관련 로컬 저장 처리
│   │   ├── TokenManager.kt/ 토큰 관리
│   │   └── TokenManagerImpl.kt
│   ├── model
│   │   ├── auth/  공통 Auth 모델
│   │   ├── trigger/  전역 UI 이벤트 모델
│   │   ├── viewtype/ 부모,아이 Type
│   │   └── UiState.kt/ 공통 UI 상태 모델
│   ├── navigation
│   │   └── Route.kt/ 앱 전역 Route 정의
│   ├── network
│   │   ├── auth/  Auth 공통 네트워크 설정
│   │   ├── di/    Retrofit, OkHttp DI 모듈
│   │   ├── model/ 공통 네트워크 응답 모델
│   │   └── monitor/ 네트워크 모니터링
│   ├── security / 보안 관련
│   └── trigger / 전역 UI 이벤트 트리거
│
├── data / 사용위치(parent) > 기능(feature) 순으로 수정
│   ├── auth
│   │   ├── local
│   │   │   ├── datasource
│   │   │   └── datasourceimpl/ Local DataSource 구현체
│   │   ├── mapper/ DTO ↔ App Model 매핑
│   │   ├── model/ Data Layer에서 사용하는 모델
│   │   │   └── DummyEntity
│   │   ├── remote
│   │   │   ├── api/ Retrofit Service
│   │   │   ├── datasource
│   │   │   ├── datasourceimpl/ Remote DataSource 구현체
│   │   │   └── dto
│   │   ├── repository/ Repository Interface
│   │   │   └── DummyRepository
│   │   └── repositoryimpl/ Repository 구현체
│   │       └── DummyRepositoryImpl
│   │
│   ├── kid/ auth와 동일한 구조
│   ├── parent/ auth와 동일한 구조
│   ├── di/ Data Layer DI 모듈
│   └── sse / 실시간 구독 관리
|
├── domain
│   └── usecase/ 비즈니스 로직 (UseCase)
|
└── presentation
|   ├── auth
|   │   ├── component/ Auth 전용 UI 컴포넌트
|   │   ├── model/ UiState, UiEvent, SideEffect
|   │   ├── navigation/ Auth 관련 Navigation
|   │   ├── viewmodel/ 상태 관리 (ViewModel)
|   │   └── AuthScreen.kt
│   |
|   ├── kid/ auth와 동일한 구조
|   ├── main/ Navigation 및 Activity (SAA)
|   └── parent/ auth와 동일한 구조
|
└── KieroApplication/  전역 애플리케이션 상태, 생명주기

[sonms]

파일 패키징 수정 고생많으셨습니다! 저두 컴포넌트 별로 나누는 것은 좋다고 생각해요!

https://www.notion.so/Domain-308ab2edd628804b9b8de27231bbd480?source=copy_link

현재 내용에는 재사용성에 대한 usecase의 장점만 나와있는데 (열심히 읽었는데 놓쳤을 수도..?)
캡슐화에 대한 부분도 있다고 생각해요 예를 들어 기능별로 묶어서 repository의 함수들 중에 필요한 부분만 열어두는 느낌으로 즉, 불필요한 기능의 노출을 막고 필요한 동작을 제공한다는 장점입니다!

물론 현재는 아직 usecase 하이브리드 전략을 사용하자라던가 기준을 정해놓지는 않아서 위 방식에 대해서는 장점이 있구나 정도만 쓰고 나중에 확실히 정해서 사용하면 좋을 것 같아요

TMI 더 적어 보자면 UseCase를 사용해서 저렇게 재사용성, 캡슐화 등 비즈니스 로직을 명명하여 개발자들도 쉽게 이름으로만 파악하여 사용할 수 있게 할 수 있는데 구권아 기준에서 보일러 플레이트라고 생각되신다면?

// 읽기 전용 기능만 모음
interface UserReader {
    fun getUserProfile(): User
    fun getPoint(): Int
}

// 쓰기 기능만 모음
interface UserWriter {
    fun updateProfile(user: User)
    fun deleteAccount()
}

// 전체 기능을 가진 인터페이스
interface UserRepository : UserReader, UserWriter

class UserRepositoryImpl @Inject constructor(
    private val dataSource: UserDataSource
) : UserRepository { // UserReader, UserWriter 모두 구현
    override fun getUserProfile() = ...
    override fun getPoint() = ...
    override fun updateProfile(user: User) = ...
    override fun deleteAccount() = ...
}

@HiltViewModel
class HomeViewModel @Inject constructor(
    private val userReader: UserReader 
) : ViewModel() {

    fun loadData() {
        userReader.getUserProfile() 
    }
}

이런식으로 interface만으로도 캡슐화를 지킬 수 있으니 고려해도 좋을 것 같아용!

[seungjae708]

키하하
깔끔한 노션 정리까지 정말 고생 많으셨습니다!! 공부 많이되네요

[seungjae708]

p1) datasourcimpl 오타 수정 부탁드려용

[dmp100]

수고 많았어용 ~ ! UseCase의 도입 기준만 먼저 같이 잘 생각해나가면 좋을거같아요 !

[dmp100]

p3 ) request로 정정하면 좋을 것 같습니다 !

[vvan2]

내가 이렇게 오타를 많이낸다. 키흐흑