[6주차/필수과제] 아키텍처 레이어 구성 요소 별 책임이 무엇이라고 생각하시나요?

[jihyunniiii]

🎤 토론 과제 - 아키텍처 레이어 구성 요소 별 책임이 무엇이라고 생각하시나요?

𝟏. 여러분이 사용하신 아키텍처가 무엇이며 어떤 식으로 폴더링 하였는지를 정리해주세요.
𝟐. 각 레이어 별 구성 요소의 책임이 무엇이라고 생각하며 아키텍처를 적용하셨는지 정리해주세요.
𝟑. 아키텍처 패턴을 적용할 때 본인이 중점적으로 생각하는 부분이나 신경쓰는 부분이 있다면 공유해주세요. 만약 없다면 아키텍처 패턴을 적용하며 어려웠던 점과 이를 어떻게 해결했는지 경험을 공유해주세요.

[boiledEgg-s]

1. 아키텍처

• 사용한 아키텍처: 클린아키텍처
• 폴더링:

  📦com.sopt.and.app
  ├─📂core
  │  ├─📂designsystem
  │  ├─📂extension
  │  ├─📂navigation
  │  ├─📂preference
  │  ├─📂state
  │  ├─📂type
  │  ├─📂util
  ├─📂data
  │  ├─📂datasource
  │  ├─📂datasourceImpl
  │  ├─📂di
  │  ├─📂dto
  │  ├─📂local
  │  ├─📂mapper
  │  ├─📂remote
  │  ├─📂repositoryImpl
  ├─📂domain
  │  ├─📂entity
  │  ├─📂repository
  │  ├─📂usecase
  ├─📂presentation
  │  ├─📂home
  │  ├─📂main
  │  ├─📂mypage
  │  ├─📂search
  │  ├─📂signin
  │  ├─📂signup
  
  

2. 레이어 별 구성요소의 책임

• core의 경우 모든 레이어에서 사용되는 공통적인 코드들을 포함해요. 예를 들면 공통 컴포넌트, 앱 테마, 색상, 타이포그래피 파일들이 여기에 속하는 것이죠.
  이외에도 자주 쓰이는 확장함수나 네비게이션의 루트를 위한 인터페이스 등도 여기에 있습니다.
• data의 경우 저장소 관리를 위한 레이어임으로 외부 그리고 내부 저장소 접근을 위한 service, datasource와 dto파일들이 포함됩니다. 클린 아키텍처 특성상 data가 domain에 의존해야하기 때문에 domain repository의 구현체도 이곳에서 관리합니다.
• domain의 경우, ui에서 datasource에 접근할 수 있게 해주는 repository 추상체를 관리합니다. 또한 앱의 주요기능을 담당하는 엔티티 또한 이곳에서 관리하죠.
• presentation의 경우, 온전히 사용자와의 상호작용을 관리할 수 있도록 관리해야 합니다. 컴포저블 함수 및 도메인 레이어의 비즈니스 로직에 접근하고 상태 관리를 도와주는 뷰모델들을 이곳에 포함시켰습니다.

3. 아키텍처 구현시 주의할 점

멀티 모듈로 구현하게 되면 각 모듈의 build.gradle 파일을 통해 의존성을 제한할 수 있습니다. 따라서 모듈 분리를 안했을 때보다 했을 때 아키텍처를 관리가 조금 수월해집니다!

최근에 팟장에게 받은 코드리뷰가 있는데요,

클린 아키텍처를 공부하셨다면 (세미나 때 했죠?) 아시겠지만 도메인에서는 프레임워크와 종속성이 최소화되어야 한다고 합니다. 따라서 도메인에 코드를 작성할 때 안드로이드 프레임워크라던가 다른 써드파티 라이브러리가 사용되지 않도록 주의해야 합니다~!

[kangyein9892]

1. 아키텍쳐 및 폴더링

선택한 아키텍처 클린아키텍처

┣ 📂 app
┣ 📂 data
┃ ┣ 📂 common
┃ ┣ 📂 datasource
┃ ┣ 📂 di
┃ ┣ 📂 dto
┃ ┃ ┣ 📂 request
┃ ┃ ┣ 📂 response
┃ ┣ 📂 mapper
┃ ┣ 📂 repository
┃ ┣ 📂 service
┣ 📂 domain
┃ ┣ 📂 exception
┃ ┣ 📂 model
┃ ┣ 📂 repository
┣ 📂 presentation
┃ ┣ 📂 component
┃ ┣ 📂 delegate
┃ ┣ 📂 extension
┃ ┣ 📂  home
┃ ┣ 📂  main
┃ ┣ 📂  my
┃ ┣ 📂  navigation
┃ ┣ 📂  search
┃ ┣ 📂  sign
┃ ┣ 📂 ui.theme
┃ ┣ 📂  util

2. 레이어별 구성요소 책임

• Data 레이어는 데이터 저장소와 관련된 책임을 가집니다. 이 저장소는 내부 저장소(SharedPreferences)나 외부 서버일 수 있습니다. 이 레이어는 Service나 Datasource를 사용해 데이터를 처리하며, 데이터 전송 객체(DTO)를 이용해 데이터를 주고받습니다.
• Domain 레이어는 애플리케이션의 비즈니스 로직을 다루며, Repository 인터페이스가 이 레이어에 존재합니다. 데이터 저장소에 직접 접근하는 것은 Data 레이어의 책임이므로, Repository의 구현은 Data 레이어에서 합니다.
• Presentation 레이어는 사용자 인터페이스(UI)와 관련된 책임을 맡습니다. 이 레이어는 사용자와의 상호작용을 처리하는 ViewModel과 UI를 구성하는 Composable 함수들로 이루어집니다. 데이터의 상태 관리는 ViewModel에서 담당하며, UI는 이 상태를 반영합니다. 또한 Presentation 레이어는 직접 데이터에 접근하지 않으며, Domain 레이어를 통해 데이터를 처리합니다.

3. 아키텍처 구현시 주의할 점

클린 아키텍처에서 domain 레이어는 순수한 자바, 코틀린 레이어인 걸 잊지 않으셨으면 좋겠습니다!
저는 dto에서 model로 바꿔주는 그런 작업들을 dto data class 함수로 구현했는데, 따로 mapper로 구분해서 하는게 책임 분리가 명확하다고 하더라고요! 그래서 뭔가 아키텍처 구현할때는 책임 분리에 대해서 생각하면서 작업해야할 것 같다는 생각을 했습니다 !!

[serioushyeon]

𝟏. 아키텍처 및 폴더링

아키텍처: 클린아키텍처
폴더링:

    📦com.sopt.and.app
    ├─📂core
    │  ├─📂component
    │  ├─📂composition
    │  ├─📂designsystem
    │  ├─📂extention
    │  ├─📂navigation
    │  ├─📂utils
    ├─📂data
    │  ├─📂api
    │  ├─📂common
    │  ├─📂database
    │  ├─📂di
    │  ├─📂mapper
    │  ├─📂model
    │  ├─📂remote
    │  ├─📂repository
    ├─📂domain
    │  ├─📂model
    │  ├─📂repository
    │  ├─📂usecase
    ├─📂presentation
    │  ├─📂home
    │  ├─📂main
    │  ├─📂mypage
    │  ├─📂search
    │  ├─📂sign
    

𝟐. 각 레이어 별 구성 요소의 책임

2.1. Core
Core 계층은 애플리케이션 전반에서 재사용 가능한 코드와 공통적인 설정
공통 로직: 여러 계층에서 재사용 가능한 유틸리티 클래스, 확장 함수, 상수, 애플리케이션 레벨의 설정 등.
플랫폼 종속적 코드: Context나 시스템 서비스와 관련된 코드
공통 리소스: 앱 전역의 스타일, 테마, 컬러, 텍스트 같은 공통 UI 리소스.
Utility: PreferenceUtils, NetworkUtils 등.
Navigation: 앱 전역의 네비게이션 설정.
Base Components: BaseActivity, BaseViewModel 등 공통 컴포넌트.

2.2. Data
Data 계층은 외부 데이터 소스와의 통신을 담당하며, 데이터를 가져오고 저장하는 역할
데이터 소스 관리: API 통신, 로컬 데이터베이스, SharedPreferences 등 다양한 데이터 소스를 관리
Repository 구현체: Domain 계층에서 정의한 Repository 인터페이스를 구현
로컬 데이터베이스: Room, SharedPreferences 등.
DTO(Data Transfer Object): 외부 데이터 형식을 정의.
Mappers: 데이터 변환 로직.

2.3. Domain
Domain 계층은 애플리케이션의 비즈니스 로직과 규칙을 포함하는 핵심 계층
비즈니스 로직: 애플리케이션에서 처리해야 할 핵심 로직을 포함
Use Cases: 단일 책임을 가진 작업 단위로, 데이터 흐름과 로직을 처리
Repository 인터페이스: Data 계층에 의존하지 않도록 추상화된 Repository를 정의
Entities: 비즈니스 로직에서 사용되는 순수한 데이터 객체

2.4. Presentation
Presentation 계층은 UI와 관련된 모든 로직과 화면을 관리
UI 상태 관리: 화면에 표시될 데이터와 상태를 관리.
사용자 상호작용 처리: 사용자 입력을 처리하고 Domain 계층과 상호작용.
뷰와 뷰모델 연결
Navigation: 화면 간 이동 로직

𝟑. 아키텍처 패턴을 적용할 때 어려웠던 점과 해결

레이어 구분은 예제를 보면서 나눠봤지만 제대로 알 지 못했던지라 domain에서 외부 라이브러리를 임포트 하기도 했었어요! 코드리뷰를 받으면서 domain은 순수 자바 코틀린 코드로 작성해야하는구나를 알게 되었습니다!
이전에는 core가 뭔지도 몰랐는데 시스템 전체에서 쓰이는 코드를 뽑아내다보니 core의 필요성을 알게되었습니다 ㅎ

[MinseoSONG]

𝟏. 아키텍처 및 폴더링

아키텍처: 클린아키텍처
폴더링:

    📦com.sopt.and.app
    ├─📂data
    │  ├─📂dataremote
    │   │ ├─📂datasource
    │   │ ├─📂datasourceimpl
    │   │ ├─📂model
    │   │ ├─📂service
    │  ├─📂repositoryimpl
    ├─📂di
    ├─📂domain
    │  ├─📂model
    │  ├─📂repository
    │  ├─📂usecase
    ├─📂presentation
    │  ├─📂model
    │  ├─📂ui
    

𝟐. 각 레이어 별 구성 요소의 책임

• Data
  외부 데이터와의 모든(저장하고 불러오고 등) 과정을 관리함.
  외부 데이터 소스(api)와 내부 데이터베이스(Room)로부터 데이터를 처리하고, 이를 위해 Service, Datasource, DatasourceImpl을 사용함.

• Domain
  데이터 처리가 아닌 데이터를 어떻게 활용할 것인지 정의하는 핵심 로직을 담당.
  UseCase: 명확히 정의된 비즈니스 로직을 수행 -> Presentation과 Data 사이의 조정자 역할.

• Presentation
  사용자와 상호작용하는 곳
  UI(View)는 단순히 데이터를 표시하고 사용자 입력을 처리함.
  ViewModel은 상태를 관리하고 필요한 데이터를 Domatin(의 UseCase)로부터 가져옴.

𝟑. 아키텍처 패턴을 적용할 때 어려웠던 점과 해결

이미 viewmodel로 구현되어있고, 아무렇게나 패키징되어 있던 프로젝트를 전체적으로 뜯어고치는데에 있어서 어려움을 겪었습니다..
그래도 세미나 자료를 다시 읽어보며 의존성에 대해 다시 생각해보고, 각 계층에 대한 고민을 해보며 과제를 해낼 수 있었던 것 같아요

어려웠던 점은 저도 모르게 자꾸만 Presentation 계층에서 바로 Data에 접근하려고 했다는 점입니다.
아무래도 지금까지 바로 viewmodel에서 api 통신을 위해 바로 data에 접근하던게 습관이 되어서 그랬던 것 같은데, 결국엔 작업할 때 계속해서 domain의 usecase를 활용했는지, 각 계층이 제대로 분리가 되었는지 꼼꼼히 확인하며 해결했습니다 .. ㅎ

[gitsuhyun]

1. 아키텍처 및 폴더링

아키텍처: 클린아키텍처
폴더링:

📦org.sopt.and
├─📂data
│  ├─📂local
│  ├─📂mapper
│  │  ├─📂todata
│  │  └─📂todomain
│  ├─📂remote
│  │  ├─📂datasource
│  │  ├─📂datasourceimpl
│  │  ├─📂model
│  │  ├─📂service
│  │  └─📂utils
│  └─📂repositoryimpl
├─📂di
├─📂domain
│  ├─📂model
│  ├─📂repository
│  └─📂type
├─📂presentation
│  ├─📂core
│  │  └─📂component
│  ├─📂home
│  ├─📂login
│  ├─📂main
│  ├─📂mypage
│  ├─📂search
│  └─📂signup
└─📂utils

2. 각 레이어 별 구성 요소의 책임

• Data Layer
  Domain Layer와 상호작용을 위해 Repository 인터페이스를 통해 도메인 계층과 연결됩니다.
  • local
    SharedPreferences, room 등 로컬 데이터 소스를 저장하고 불러옵니다.
  • mapper
    domain, 또는 data로 각 모델을 변환해서 넘겨주는 역할을 합니다.
  • remote
    API와의 통신을 담당합니다.
  • repositoryimpl
    repository 인터페이스를 구현하는 클래스들로, 데이터 소스에서 데이터를 조합하여 도메인 계층에 전달합니다.
• DI Layer
  DataSourceModule, NetworkModule 등등 각 계층에서 의존성을 주입하고 관리하는 역할을 합니다.
• Domain Layer
  비즈니스 로직을 담고 있으며, 외부 서비스에 대한 의존성이 없습니다. 대신, Data Layer의 Repository 인터페이스를 통해 데이터를 처리합니다.
  • model
    data로 부터 변환하여 받은 data class입니다.
  • repository
    도메인 계층에서 데이터를 가져오고 데이터를 저장하는 인터페이스를 제공합니다.
  • type
    enum class로 정의한 타입입니다.
• Presentation Layer
  Domain Layer에서 제공하는 비즈니스 로직을 호출하여 UI를 갱신하고, 사용자와의 상호작용을 처리합니다.

3. 아키텍처 패턴을 적용할 때 중요하게 생각하는 점

domain 계층은 비즈니스 로직을 담기때문에 다른 로직이 섞여들어가지 않도록 하는게 중요합니다. 따라서 다른 계층, 또는 Third Party에서 import 된 것이 있는지 여러번 검토하였습니다.

[jangsjw]

𝟏. 아키텍처 및 폴더링
아키텍처: 구글권장아키텍쳐
폴더링:
📦org.sopt.and
├─📂data
│ ├─📂api
│ ├─📂dto
│ ├─📂repository
├─📂presentation
│ ├─📂auth
│ │ ├─📂component
│ │ ├─📂screen
│ │ └─📂viewmodel
│ ├─📂main
│ │ ├─📂component
│ │ ├─📂screen
│ │ └─📂viewmodel
│ └─📂navi
└─📂utils

2. 각 레이어 별 구성 요소의 책임

1. Data 레이어
   구성요소: api, dto, repository
   책임:네트워크 호출 및 로컬 데이터 소스 접근.
   외부 데이터 모델(DTO)을 도메인 계층의 데이터로 변환하여 Presentation 계층에 제공. 데이터를 처리하는 Repository 구현체를 제공.

2. Presentation 레이어
   구성요소: auth, main, navi
   ViewModel:UI 상태를 관리하며 View와 데이터 계층 간의 중간 역할을 수행.
   데이터 흐름을 제어하고 상태(State)를 관리.

Screen:사용자와 상호작용하는 UI 컴포넌트를 정의.
ViewModel을 구독하여 UI를 업데이트.

Component:공통적으로 사용하는 UI 요소를 재사용 가능하게 작성.

3. Utils
   책임:전체적으로 사용하는 유틸리티 클래스 (예: 네트워크 상태 확인, 문자열 포맷 등).

𝟑. 아키텍처 패턴을 적용할 때 어려웠던 점과 해결
비교적 쉬운 구글 권장아키텍처로 진행했습니다. 아키텍처 패턴을 적용하며 새로운 파일들도 생성해야 했고 이 과정에서 기존 로그인 및 mypage 오류가 났습니다. 이 부분이 가장 어려웠고 시간이 많이 소요됐던 것 같습니다! 이후 파일을 생성하면서 중복된 코드들을 고치면서 해결했습니다!

[ThirFir]

📦org.sopt.and
├─📂app
│  ├─📂adapter
│  ├─📂di
│  ├─ Application.kt
├─📂data
│  ├─📂api
│  │  ├─📂local
│  │  ├─📂remote
│  ├─📂datasource
│  │  ├─📂local
│  │  ├─📂remote
│  ├─📂dto
│  │  ├─📂response
│  │  ├─📂request
│  ├─📂entity
│  └─📂repository
├─📂domain
│  ├─📂exception
│  ├─📂model
│  ├─📂repository
│  ├─📂usecase
│  └─📂util
├─📂presentation
│  ├─📂ui
│  │  ├─📂component
│  │  ├─📂navigation
│  │  ├─📂screen
│  │  │  ├─📂home
│  │  │  │  ├─📂composable
│  │  │  │  └─📂viewmodel
│  │  │  ├─📂my
│  │  │  │  ├─📂composable
│  │  │  │  └─📂viewmodel
│  │  │  ├─📂...
│  │  ├─📂state
│  │  ├─📂theme
│  │  └─📂util
│  └─📂util
└─MainActivity.kt

• presentation 모듈 : UI 담당
• domain 모듈 : 비즈니스 로직 담당
• data 모듈 : 데이터 원 출처 접근
• app 모듈 : 모든 모듈에 대한 의존성을 지니며, 앱의 진입점처럼 작용. Hilt Module 작성

아키텍처를 분리하며 제가 가장 중요하게 생각하는 원칙은 모호함이 없어야 한다는 점입니다. 어떤 파일이 여러 패키지에 속할 수 있다면 패키징이 제대로 이루어진 것인지 다시 고민해 볼 필요가 있다고 생각합니다.

또한 data 레이어는 데이터의 원 출처에 접근한다는 역할을 가진만큼, 그 출처가 remote인지 local인지 명확하게 분리하는 것이 중요하다고 생각합니다. 따라서 저는 이를 명확히 하기 위해 local과 remote를 명시적으로 분리하는 것을 선호하며, 이에 맞춰 dto와 entity는 별개의 패키지로 분리합니다. dto는 remote, entity는 local에 대한 모델을 의미하게 되는 것입니다.

domain 레이어의 경우, 대부분 비즈니스 로직을 담당합니다. 저는 요즘에는 발생할 수 있는 모든 예외를 domain 레이어에서 구분하여 사용하는데, 커스텀 예외 클래스를 정의하여 비즈니스 로직에 대한 결과를 presentation까지 보내주는 방식을 고안하여 사용하고 있습니다.

[Hyobeen-Park]

사용한 아키텍처

• 클린 아키텍처

폴더링

📦com.sopt.and.app
├─📂core
│  ├─📂designsystem
│  ├─📂extension
│  ├─📂navigation
│  ├─📂state
├─📂data
│  ├─📂datasource
│  ├─📂datasourceImpl
│  ├─📂di
│  ├─📂dto
│  ├─📂mapper
│  ├─📂repositoryImpl
│  ├─📂service
├─📂domain
│  ├─📂entity
│  ├─📂repository
│  ├─📂usecase
├─📂feature
│  ├─📂home
│  ├─📂main
│  ├─📂my
│  ├─📂search
│  ├─📂signin
│  ├─📂signup

레이어별 구성 요소의 책임
data : 저장소 관리 -> 내 / 외부 저장소에 접근하는 곳!
domain : UI에서 data에 접근할 수 있도록 해주는 연결다리 / 비즈니스 로직들이 들어갑니다
feature : UI를 통해 사용자와 직접 상호작용 하는 곳!

아키텍처 적용 시 신경쓰는 부분, 어려웠던 부분
엔티티를 도메인 레이어로 옮기는 과정에서 @StringRes / @DrawableRes 를 적용해뒀던 부분을 그대로 같이 옮겼던 경험이 있습니다!!(바로 코리가 달렸던...ㅋㅋㅋㅋ) 사실 도메인은 순수 자바 / 코틀린 파일만 들어갈 수 있습니다!! 그렇기 때문에 꼭 다른 의존성이 추가되지 않도록 유의하고, 기존 코드들을 아키텍처를 적용하도록 리팩토링하시는 분들은 본인도 모르는 사이에 이런 실수를 할 수 있으니 한번씩 확인하는게 좋을 것 같아요!!
또한 도메인 뿐만 아니라 다른 레이어에서도 불필요한 의존성을 가지고 있지 않은지 유의하고, 의존성의 방향을 생각하며 적용합니다!!

[angryPodo]

1. 아키텍처 및 폴더링

Clean Architecture를 적용했으며 다음과 같은 구조로 구성했습니다:

org.sopt.and/
├── domain/                 # 비즈니스 로직 계층
│   ├── entity/            # 도메인 모델
│   ├── repository/        # 레포지토리 인터페이스
│   └── usecase/           # 유스케이스
├── data/                  # 데이터 계층
│   ├── repository/        # 레포지토리 구현체
│   ├── remote/            # 원격 데이터 관련
│   │   ├── api/          # API 인터페이스
│   │   ├── model/        # DTO 모델
│   │   └── source/       # 데이터소스
│   ├── local/            # 로컬 데이터 관련
│   └── mapper/           # 데이터 변환기
└── presentation/         # UI 계층
    ├── auth/             # 인증 관련 화면
    ├── home/            # 홈 화면
    └── component/       # 재사용 가능한 컴포넌트

2. 각 레이어별 책임

• Domain Layer:

  • 비즈니스 로직을 포함하며 다른 레이어에 의존성을 가지지 않음
  • UseCase를 통해 비즈니스 규칙을 정의
  • Repository 인터페이스를 통해 데이터 계층과 통신

• Data Layer:

  • Domain Layer에서 정의한 Repository를 실제로 구현
  • 로컬/원격 데이터 소스 관리
  • DTO와 도메인 모델 간의 매핑 처리

• Presentation Layer:

  • UI 상태 관리 (ViewModel)
  • 사용자 이벤트 처리
  • UI 컴포넌트 구성 (Compose)

3. 중점적으로 생각하는 부분

• 의존성 방향: 항상 안쪽 레이어를 향하도록 관리
• 관심사 분리: 각 레이어가 자신의 책임만 수행하도록 구성
• 테스트 용이성: 각 컴포넌트를 독립적으로 테스트할 수 있도록 설계

어려웠던 점:

1. DataStore와 같은 안드로이드 의존성이 있는 코드를 Clean Architecture에 맞게 구성하는 것
2. UseCase 분리 시 비즈니스 로직의 범위 결정

해결방법:

1. DataSource를 인터페이스로 추상화하고 구현체를 Data Layer에 두어 의존성 역전
2. 단일 책임 원칙을 기준으로 UseCase를 분리하고, 필요한 경우 UseCase 간 조합을 통해 복잡한 비즈니스 로직 구현

[kamja0510]

1. 아키텍처

• 사용한 아키텍처: 클린아키텍처
• 폴더링:

📦com.sopt.and.app
├─📂data
│  ├─📂datasource
│  ├─📂mapper
│  ├─📂model
│  ├─📂repositoryImpl
│  ├─📂service
├─📂domain
│  ├─📂model
│  ├─📂repository
│  ├─📂usecase
├─📂presentation
│  ├─📂component
│  ├─📂home
│  ├─📂myinfo
│  ├─📂navigation
│  ├─📂search
│  ├─📂signin
│  ├─📂signup
│  ├─📂util
│  ├─📂viewmodelfactory

2. 레이어 별 구성요소의 책임

1. domain : 비즈니스 로직들을 담당하고 있는 계층. 의존성이 없어야 하므로 data 계층의 datasource에 접근하기 위해서 repository 패턴을 이용했습니다.
2. data : 기본적으로 datasource를 관리하는 계층. domain 레이어의 repository의 구현체를 가져 domain이 datasource에 접근 할 수 있도록 합니다. mapper를 통해 domain에서 사용하는 entity로 변환할 수 있게도 함.
3. presentation : MVVM구조로 UI 로직들이 들어가고, viewmodel에서 usecase의 의존성을 가질 수 있도록(?) viewmodelfactory를 만들어 usecase를 받을 수 있도록 함.

3. 아키텍처 구현시 알게된 꿀팁이나 어려웠던점

의존성을 가지는 건지 아닌지 헷갈리는 경우가 많았는데 종명님의 조언으로 import문을 보고 각 계층에서 의존성 방향이 잘못되는 경우를 쉽게 알 수 있게 되었습니다.

저는 어려웠던점이 너무 많았지만 그중 제일 고민을 했던 것은 presentation 계층에서 어떻게 dataSource의 의존성을 없앤체로 통신을 할 수 있을지가 고민이었습니다. 저는 예인님의 도움을 받아 원래는 viewmodel의 인자로 repositoryimple을 인자로 받는 usecase를 넣었었다가 repository에서 static repository구현체를 만드는 함수를 선언해 viewmodel의 인자로 GetMyHobbyUseCase( getMyHobbyRepository = GetMyHobbyRepository.create() ) 요런 식의 usecase를 줄 수 있게 되어 data에 대한 의존을 벗어날 수 있었습니다. viewmodel에서 인자를 받는 방법은 효은님의 합세 꿀팁 공유를 참고하였습니다.

[t1nm1ksun]

1. 아키텍처

• 사용한 아키텍처: 클린아키텍처
• 폴더링:

📦org.sopt.and
├─📂data
│  ├─📂datalocal
│  │  ├─📂datasource
│  │  ├─📂datasourceimpl
│  ├─📂dataremote
│  │  ├─📂datasource
│  │  ├─📂datasourceimpl
│  │  ├─📂model
│  │  ├─📂service
├─📂di
├─📂domain
│  ├─📂model
│  ├─📂repository
│  ├─📂usecase
├─📂presentation
│  ├─📂model
│  ├─📂ui
│  │  ├─📂component
│  │  ├─📂home
│  │  ├─📂main
│  │  ├─📂mypage
│  │  ├─📂search
│  │  ├─📂signin
│  │  ├─📂signup
│ ├─📂util
├─📂ui.theme
WaveApp

2. 레이어 별 구성요소의 책임

1. domain : 비지니스 로직 담당
2. data : 데이터 소스관리(외부와 로컬) 및 필요에 따라 mapper를 통한 데이터 변환
3. presentation : 사용자와 상호작용하는 UI 담당

3. 아키텍처 구현시 주의할 점

레이어 간 의존성은 반드시 규칙을 따라야 하며, Presentation Layer가 Data Layer를 직접 참조하지 않도록 주의
과제 수행 시 폴더링으로 잘 구분해놓고 무지성 option+enter로 직접 참조했다가 리뷰 달림 ㅠ

[jm991014]

1. 아키텍처 및 폴더링

Clean Architecture

📦com.sopt.and.app
├─📂data
│  ├─📂datasource
│  ├─📂datasourceImpl
│  ├─📂di
│  ├─📂Interceptor
│  ├─📂mapper
│  ├─📂model
│  ├─📂repositoryImpl
│  ├─📂service
├─📂domain
│  ├─📂entity
│  ├─📂exception
│  ├─📂repository
│  ├─📂usecase
├─📂presentation
│  ├─📂authentication
│  ├─📂common
│  ├─📂extension
│  ├─📂home
│  ├─📂main
│  ├─📂mypage
│  ├─📂navigation
│  ├─📂search
│  ├─📂theme
│  ├─📂util

각 레이어 별 구성요소의 책임

data: local 및 remote 데이터 관리, domain 레이어의 종속성 최소화를 위한 mapper 로직
domain: 전반적인 비즈니스 로직을 담당
presentation: 유저와 상호작용하는 UI를 담당

주의할 점

import 문을 확인하며 레이어 간 의존성 방향이 잘못되지 않았는지 확인하기

[HAJIEUN02]

🏛️ 아키텍처 및 폴더링

Clean Architecture를 사용했습니다.

📂 org.sopt.and
┣ 📂 data
┃ ┣ 📂 datasource
┃ ┃ ┣ 📂 local
┃ ┃ ┣ 📂 remote
┃ ┣ 📂 datasourceImpl
┃ ┃ ┣ 📂 local
┃ ┃ ┣ 📂 remote
┃ ┣ 📂 dto
┃ ┃ ┣ 📂 request
┃ ┃ ┣ 📂 response
┃ ┣ 📂 interceptor
┃ ┣ 📂 repositoryImpl
┃ ┣ 📂 service
┣ 📂 di
┣ 📂 domain
┃ ┣ 📂 model
┃ ┣ 📂 repository
┃ ┣ 📂 usecase
┣ 📂 presentation
┃ ┣📂 model
┃ ┣📂 type
┃ ┣📂 ui
┃ ┃ ┣📂 component
┃ ┃ ┣📂 navigator
┃ ┃ ┣📂 my
┃ ┃ ┣📂 auth
┃ ┃ ┣📂 home
┃ ┃ ┣📂 search
┣ 📂 util

💭 각 레이어 별 구성 요소의 책임

1. data

데이터 생성, 저장, 변경 방식을 결정하는 규칙 등의 비즈니스 로직을 포함하는 레이어로 Repository Pattern을 이용해 여러 개의 데이터소스를 각각 포함할 수 있는 Repository interface를 구현했습니다. 파일, 네트워크 소스, 로컬 DB와의 소통과 같은 데이터 작업을 위해 앱과 시스템 간의 다리 역할을 하는 DataSource를 해당 레이어에 구현했습니다.

2. domain

복잡한 비즈니스 로직이나 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 진행하는 레이어입니다. 하나의 기능을 담당하는 비즈니스 로직을 캡슐화하기 위해 UseCase를 사용했으며, 이는 실제 비즈니스 로직을 포함하는 부분입니다. 프레젠터나 뷰모델로부터 전달된 요청을 처리하고 데이터를 가공하여 반환합니다. 또한 Data layer와의 의존성을 분리하기 위해 Repository를 해당 레이어에서 구현했습니다. Repository는 외부 데이터 원본과의 상호 작용을 담당하는 부분으로 데이터를 가져오고 저장하는 작업을 수행합니다. 앱 내의 핵심 데이터 구조인 Entity를 domain > model에 구현했으며, 이는 DB나 네트워크를 통해 가져온 데이터를 객체로 변환한 상태입니다.

3. presentation

UI Layer. 화면에 데이터를 "표시"하는 기능을 담당하는 레이어입니다. 사용자와 상호작용 또는 외부 입력으로 인해 데이터가 변할 때마다 반영하도록 업데이트 되어야 하는 부분입니다. 화면에 데이터를 렌더링하는 UI 요소인 Screen과 데이터를 보유하고 이를 UI에 노출, 비즈니스 로직을 처리하는 state holder로 분리됩니다.(ex. ViewModel)

주요 원칙

1. 의존성 역전 원칙 : 고수준 모듈은 저수준 모듈에 의존해서는 안되며, 양쪽 모듈 모두 추상화에 의존해야 합니다.
2. 경계의 분리 : 시스템을 여러 영역으로 나누고, 각 영역 사이의 인터페이스를 정의해 각 영역의 독립성을 보장해야 합니다.
3. 인터페이스 분리 원칙 : 클라이언트가 자신이 사용하는 메소드에 의존하지 않아야 하며, 인터페이스는 클라이언트의 요구에 딱 맞는 형태로 분리되어야 합니다.

🤔 아키텍처 패턴을 적용 시 중점적으로 생각하는 부분

요즘 특히 신경쓰는 부분은 아키텍처 패턴을 "얼머나 엄격하게 적용해야 하는가"입니다. 저번 세미나 때 토론했듯, 패키징 방식이나 구현 위치/방법 등은 개발자의 취향, 고려하는 확장 기술이나 기능의 범위에 따라 다릅니다.
지금은 개인 과제이기 때문에 제 마음대로 했지만, 팀원들과 함께 프로젝트를 진행할 때 미리 정해야 할 부분들이 자꾸 추가가 되어요😣😱

1. mapper를 따로 구현하는 것이 좋을지, dto에서 바로 호출할 수 있는 식으로 구현하는 것이 좋을지(엄격한 의존성 분리 vs 유지보수 및 가독성의 편리함)
2. util 패키지를 layer별로 구현하는 것이 좋을지, 모든 layer가 util에 의존을 갖도록 최상단, 즉 layer들과 같은 계층에 하나만 구현하는 것이 좋을지(추후 멀티모듈로 확장할 가능성 및 엄격한 의존성 분리 vs 가독성 및 중복 코드 제거, 구현 편의)
3. 예외 처리는 어디서 해야 하는가(runCatching을 repository에서 해야 하는지 viewModel에서 해야 하는지 등..)
   ... 또 분명 더 있었던 것 같은데 까먹음 ㅠㅠㅋㅋ 정리 잘 해놓을게요 앞으로..

사실 클린 아키텍처라는 건 "따라야 하는 스타일"이 아니라 "지향해야 할 규칙"이라는 말이 기억에 남는데요. 언제나 팀원들과 아키텍처에 대해 확실히 이해하고 우리만의 컨벤션을 정한 뒤 프로젝트를 수행하는 것이 좋겠구나.. 를 최근에 많이 느꼈서요!

[beom84]

아키텍쳐

---

• 사용 아키텍쳐 : Clean Architecture
• 폴더링 구조

📦com.sopt.and.app
├─📂core
│  ├─📂designsystem      
│  ├─📂extension        
│  ├─📂navigation       
├─📂data
│  ├─📂remote          
│  │  ├─📂datasource    
│  │  ├─📂datasourceimpl           
│  │  ├─📂model         
│  ├─📂mapper            
│  ├─📂repository    
│  ├─📂service       
├─📂di            
├─📂domain
│  ├─📂model       
│  ├─📂repository  
│  ├─📂usecase     
├─📂presentation
│  │  ├─📂home      
│  │  ├─📂login     
│  │  ├─📂myprofile    
│  │  ├─📂search     
│  │  ├─📂signup      

---

레이어별 구성요소의 책임

• core
  • 코드 전반에서 사용하는 공통적인 코드들 위주로 모아놨습니다.
• data
  • 서버와 통신하는 코드와 domain과의 의존성 역전을 위한 repository 코드를 생각하며 넣었습니다.
• di
  • 의존성 주입을 위한 모듈 코드를 넣어놓았습니다.
• domain
  • 클린아키텍쳐의 핵심요소이기게 최대한 나중에 바뀌지 않아야한다는 생각으로 만들었습니다.
• presentation
  • view를 관리하는 코드를 넣어놓았습니다!

---

어려웠던 점

• hilt와 함깨 클린아키텍쳐를 처음 적용하면서 이해하지 못한 부분이 많아 전체적으로 오류도 많이 나고 많은 시행착오가 있었습니다. 하지만 백문이 불여일견이라고 몸으로 부딪히며 코드를 짜고 다양한 아티클을 읽으니 조금은 이해가 되었던것 같습니다.

[0se0]

data
|--datasorce
|--datasorceimpl
|--di
|--repositoryimpl
|--response
|--sevice

domain
|--entity
|--repository

feature
|--View
|--ViewModel
|--model

데이터 정제
DB 데이터는 반드시 매퍼를 통해 도메인 객체로 변환
매핑 과정에서 데이터 검증과 형식 변환
잘못된 데이터는 도메인 레이어에 절대 도달하지 않음

책임의 명확한 분리
도메인 레이어: 비즈니스 규칙과 제약조건 정의
매퍼: 데이터 변환과 검증
레포지토리: 영속성 처리

아키텍처 구현시 주의할 점

1. 의존성 규칙 엄격한 준수(의존성 역전 원칙 적용)
2. 에러 처리 체계 일원화
3. 레이어 간 데이터 변환 책임

[yskim6772]

🗂️ 1. 아키텍처 및 폴더링

• 아키텍처 : 클린 아키텍처
• 폴더링 :

📦com.sopt.and.app
┣ 📂 core
┃ ┣ 📂 designsystem
┃ ┃ ┣ 📂 component
┃ ┣ 📂 utils
┣ 📂 data
┃ ┣ 📂 datasource
┃ ┣ 📂 datasourceimpl
┃ ┣ 📂 di
┃ ┣ 📂 dto
┃ ┃ ┣ 📂 request
┃ ┃ ┣ 📂 response
┃ ┣ 📂 mapper
┃ ┣ 📂 repositoryimpl
┃ ┣ 📂 service
┣ 📂 domain
┃ ┣ 📂 entity
┃ ┣ 📂 repository
┃ ┣ 📂 usecase
┣ 📂 feature
┃ ┣ 📂 home
┃ ┣ 📂 model
┃ ┣ 📂 mypage
┃ ┣ 📂 nav
┃ ┣ 📂 search
┃ ┣ 📂 signin
┃ ┣ 📂 signup

💪🏻 2. 각 레이어 별 구성 요소의 책임

• Core : 모든 레이어에서 활용되는, 공통 로직 관련된 코드들이 담겨있는 부분입니다. 특정 뷰에서만 사용되지 않고 2개 이상의 뷰에서 사용되는 공통 컴포넌트나, 자주 사용되는 확장함수 등이 Core에 포함됩니다.
• Data : 데이터를 불러오고 데이터 관련 책임을 갖는 모든 로직을 포함하는 레이어입니다. 데이터 소스를 관리하고, Repository의 구현체 및 서버 통신 로직에 관련된 모든 코드들이 Data 레이어에 작성됩니다. Dto, Dto와 Domain 레이어의 모델 간의 매핑을 해주는 mapper 함수 등도 Data 레이어에 포함됩니다.
• Domain : 비즈니스 핵심 로직이 담겨 있는, 순수 코틀린 코드로만 이루어진 레이어입니다. 가장 안쪽에 존재하는 계층으로 다른 계층으로의 의존성을 갖지 않습니다. 데이터 저장소 역할을 하는 Repository가 Domain 레이어에 존재하며, 이에 따라 Repository의 구현체는 Domain 레이어가 아니라 Data 레이어에 존재해야 합니다.
• Feature : UI와 관련된 로직, 사용자와 상호작용하는 로직을 포함하는 레이어입니다. 데이터를 표시하는 것을 담당하며, UI 관련 코드와 ViewModel을 포함합니다. 공통 컴포넌트가 아닌 내부 컴포넌트 또한 Feature(Presentation) 레이어 안에 각 화면별 폴더 안에 위치합니다.

⭐️ 3. 아키텍처 패턴을 적용할 때 중요하게 생각하는 점

Domain 레이어가 하는 일이 무엇인지, 어떤 점에 유의하여 의존성 관리를 해야 하는지가 매우 중요하다고 생각합니다.
반드시 Data가 Domain에 의존하게끔 구현해야 하며, Domain 레이어는 Data 레이어로의 의존성이 없어야 합니다.
합세 리뷰에서도 받은 피드백인데, Domain 레이어에 있는 코드에 data와 연관된 import가 있게 되면 의존성 법칙에 위배되는 것이므로, 반드시 Domain 레이어에는 순수 코틀린 코드로만 구성된, 외부 라이브러리의 import도 포함되지 않은 코드만 담아야 합니다.

이에 따라 많이들 하는 실수 중 하나인, Repository에서는 절대 dto를 바로 사용하면 안 된다는 점이 중요한 것 같습니다. 반드시 mapper 함수를 통해 model을 생성하여, Repository에서는 이 model을 활용해야 합니다. (model은 Domain 레이어의 entity 폴더 안에 위치시켰습니다.)

[wjdrjs00]

아키텍처

• 적용: 클린아키텍처
• 폴더링:

  org.sopt.and
  ├─ core
  │  ├─ designsystem
  │  ├─ extension
  │  ├─ navigation
  │  ├─ network
  ├─ data
  │  ├─ datasource
  │  ├─ di
  │  ├─ dto
  │  ├─ mapper
  │  ├─ repositoryImpl
  │  ├─ service
  │  ├─ util
  ├─ domain
  │  ├─ model
  │  ├─ repository
  │  ├─ usecase
  ├─ presentation
  │  ├─ home
  │  ├─ main
  │  ├─ mypage
  │  ├─ search
  │  ├─ signin
  │  ├─ signup
  

레이어별 구성요소 책임

data:
→ 데이터 관련 모든 처리(로컬, 외부 데이터)에 대한 책임
→ 데이터를 도메인 모델, 엔티티와의 매핑처리에 대한 책임
domain:
→ 해당 앱의 핵심 비즈니스 로직을 수행
→ 일반적으로 특정 기술이나 프레임워크에 의존하지 않는 순수 Kotlin 코드로 구성함
presentation:
→ ui 구성 및 사용자와의 상호작용 처리 대한 책임
→ 비즈니스로직이 아닌 순수한 ui로직(화면표시, 이벤트처리)만의 책임 가짐

아키텍처 적용간 중요하게 생각하는 점

• 각 계층이 자신이 가져야하는 책임만을 가지도록 구현하기(역할분리)
  • 제가 생각하는 아키텍처는 결국 실제 서비스(제품)는 개인이 아닌 팀단위로 개발이 이루어지는 환경이 일반적인데, 이 때 정형화된 구조(아키텍처)를 가져감으로써 유지보수성을 높이기 위해서 사용한다고 생각합니다. 이를 위해서 각 계층과 또 계층에 속한 각각의 역할들이 자신이 책임져야하는 부분에 대해서만 책임을 가질 수 있도록 구조를 나누고 또 코드를 구현하는 것이 중요하다고 생각합니다.(이를 지키지 않으면 사실상 아키텍처를 적용하는 이점이 사라진다??)
  • 또 이를 잘 지키면 변경사항이 발생하는 경우에 해당 부분만을 변경을 해주어 추가적인 변경사항이 발생하지 않도록 방지할 수 있다고 생각합니다.

[Roel4990]

아키텍처 : 클린 아키텍처

📦org.sopt.and
├── domain
│   ├── entity
│   │   └── User.kt
│   └── repository
│       ├── DataStoreRepository.kt
│       ├── DataStoreRepositoryImpl.kt
│       ├── UserRepository.kt
│       └── UserRepositoryImpl.kt
├── data
│   └── datasource
│       ├── DataStoreDataSource.kt
│       ├── DataStoreDataSourceImpl.kt
│       ├── UserDataSource.kt
│       └── UserDataSourceImpl.kt
├── di
│   ├── DataModule
│   ├── DataStoreModule
│   ├── DispatcherModule.kt
│   └── NetworkModule
├── network
│   ├── adapter
│   │   ├── ApiResult
│   │   ├── ApiResultCall
│   │   └── ApiResultCallAdapterFactory
│   ├── interceptor
│   │   └── AuthInterceptor
│   ├── model
│   │   ├── request
│   │   │   ├── LoginRequest
│   │   │   └── SignUpRequest
│   │   └── response
│   │       ├── SignUpResponse
│   │       ├── UserHobbyResponse
│   │       └── UserTokenResponse
│   │       └── BaseResponse.kt
│   └── service
│       └── UserService
├── presentation
│   ├── components
│   │   └── topbar
│   ├── navigation
│   ├── theme
│   │   ├── Color.kt
│   │   ├── Theme.kt
│   │   ├── Type.kt
│   │   ├── WaveColors.kt
│   │   ├── WaveTheme
│   │   └── WaveTypography.kt
│   ├── ui
│   │   ├── home
│   │   │   ├── HomeContract.kt
│   │   │   ├── HomeScreen.kt
│   │   │   └── HomeViewModel.kt
│   │   ├── myPage
│   │   │   ├── MyPageContract.kt
│   │   │   ├── MyScreen.kt
│   │   │   └── MyScreenViewModel.kt
│   │   ├── search
│   │   │   ├── SearchContract.kt
│   │   │   ├── SearchScreen.kt
│   │   │   └── SearchViewModel.kt
│   │   ├── signIn
│   │   │   ├── SignInContract.kt
│   │   │   ├── SignInScreen.kt
│   │   │   └── SignInViewModel.kt
│   │   ├── signUp
│   │   │   ├── SignUpContract.kt
│   │   │   ├── SignUpScreen.kt
│   │   │   └── SignUpViewModel.kt
│   ├──utils
│   ├── AuthViewModel
│   ├── MainActivity.kt
│   └── MainViewModel
├── utils
├── AndSopt
└── Constants

각 레이어 별 구성 요소의 책임

Domain Layer

애플리케이션의 핵심 비즈니스 로직을 수행합니다. 애플리케이션의 비즈니스 규칙과 정책을 정의하고, 도메인 모델(Entity)과 비즈니스 유스케이스(Use Case)를 포함합니다. 도메인 레이어는 데이터 레이어나 프레젠테이션 레이어와의 직접적인 연결이 없어야 하며, 순수하게 비즈니스 로직만을 담당해야 합니다.

Data Layer

데이터 관련 모든 처리를 담당합니다. 데이터 소스로부터 데이터를 가져오고, 적절한 형태로 변환하여 도메인 레이어에 제공합니다.
이 레이어는 로컬 데이터베이스, 웹 API 등 다양한 데이터 소스와의 통신을 관리하며, 데이터를 캐싱, 저장, 검색하는 책임을 집니다.

Network Layer

네트워크 요청을 처리하는 로직을 포함합니다. API 호출을 관리하고, 네트워크 응답을 파싱하여 데이터 레이어에 전달합니다.
이 레이어는 Retrofit, OkHttp 등의 라이브러리를 사용하여 HTTP 통신을 처리하며, 네트워크 상태나 에러 처리를 관리합니다.

Presentation Layer

사용자 인터페이스와 상호작용을 관리합니다. MVI 패턴을 통해 상태, 이벤트, 사이드 이펙트를 관리하고, 사용자로부터의 입력을 처리하여 해당 이벤트를 모델로 전달합니다.
구성 요소:
Contract: View와 ViewModel 사이의 인터페이스를 정의합니다.
Screen: 사용자에게 보여지는 UI 컴포넌트를 구현합니다.
ViewModel: 화면 상태의 로직을 관리하고, View로부터의 이벤트를 처리하여 필요한 상태 변화를 발생시키거나 데이터 레이어와 통신합니다.

아키텍처 패턴을 적용하며 어려웠던 점과 이를 어떻게 해결했는지 경험

안드로이드 경험이 많지 않았기 때문에 적용 시에 어떤 방식이 좋을지 고민이 많았어서 다른 사람들의 코드를 많이 참고하고 또한 공부하면서 진행했던것 같습니다. 나중에는 다른 잘하는 분들 처럼 저만의 커스텀된 패턴 구조 및 아키텍처를 사용하면 좋을 듯 싶습니다. 아직 해결했진않고 해결해 나가야될 문제 같습니다 ㅎㅎㅎ..🤣

[hyoeunjoo]

1. 폴더링

org,sopt.and
┣ 📂 core
┃ ┣ 📂 component
┣ 📂 data
┃ ┣ 📂 di
┃ ┣ 📂 dto
┃ ┃ ┣ 📂 request
┃ ┃ ┣ 📂 response
┃ ┣ 📂 repositoryimpl
┃ ┣ 📂 service
┣ 📂 domain
┃ ┣ 📂 entity
┃ ┣ 📂 mapper
┃ ┣ 📂 repository
┃ ┣ 📂 usecase
┣ 📂 feature
┃ ┣ 📂 home
┃ ┣ 📂 mypage
┃ ┣ 📂 nav
┃ ┣ 📂 search
┃ ┣ 📂 login
┃ ┣ 📂 signup
┣ 📂 util
┃ ┣ 📂 extension

2. 각 레이어 별 구성 요소의 책임

core : 모든 레이어에서 사용되는 부분을 넣었습니다. 공통으로 쓰이는 컴포넌트를 여기에 넣었습니다.
data : data는 직접적으로 데이터 소스(API,Database) 와 연결되는 곳입니다. 데이터를 저장하고 관리합니다.
domain : 비지니스 로직을 담당합니다. 외부 의존성은 가지지 않으며 코틀린으로 이루어진 순수 로직을 구현해야합니다. 데이터를 가공하거나 처리(mapper)합니다.
presentation : 화면에 표시되는 부분. 사용자와 상호작용. ViewModel을 통해 Domain 계층의 데이터를 구독하고 화면에 표시합니다.

3. 아키텍처 적용간 중요하게 생각하는 점

저는 mapper를 만드는 것을 참 좋아하는데요..^^.. mapper를 활용하면 의존성을 명확히 분리할 수 있어 유지보수성이 향상될 뿐만 아니라, RepositoryImpl 클래스의 가독성 또한 크게 개선되는 장점떄문에 꼭 만들게 되는 것 같습니다. 이번 합동 세미나에서 아키텍처 패턴과 폴더 구조를 설정하는 과정에서 이러한 의존성 분리가 왜 중요한지, 그리고 이를 통해 어떤 이점이 있는지 더욱 깊이 이해할 수 있었습니다.

[yihwanggeun]

1. 폴더링

---

📦 com.sopt.and.app
├─📂 core
│  ├──📂 data
│  │   ├──📂 datasource
│  │   ├──📂 datasourceImpl
│  │   ├──📂 dto
│  │   ├──📂 repositoryImpl
│  │   └──📂 service
├─📂 domain
│  ├──📂 entity
│  └──📂 repository
├─📂 presentation
│  ├──📂 auth
│  ├──📂 common
│  ├──📂 home
│  ├──📂 mypage
│  └──📂 search

2. 각 레이어 별 구성 요소의 책임

---

이전에 정리해둔 내용이 있어 이 내용으로 대체하겠습니다.
https://velog.io/@yellu/Android-%ED%81%B4%EB%A6%B0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EC%99%80-Android-Architecture
https://velog.io/@yellu/Android-%ED%81%B4%EB%A6%B0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EC%99%80-Android-Architecture-2-Now-In-Android-%EC%98%88%EC%8B%9C

3. 아키텍처 적용간 중요하게 생각하는 점

---

의존성도 물론 중요하고 각각의 역할을 충실히 하는 것도 중요하지만 제가 가장 중요하게 생각하는 부분은 최소 역할인 것 같아요
각 계층, 각 클래스에서 더 많은 로직을 담을 수 있어도 최소한의 기능만 들어가게 클래스나 파일을 구성하면 이후에 그 파일들을 조합하여 사용하기에 좋아
재사용성이 높아진다고 생각합니다!

[chrin05]

1. 폴더링
📦com.sopt.and.app
├─📂core
│ ├─📂designsystem
│ │ ├─📂component
├─📂data
│ ├─📂datasource
│ ├─📂datasourceimpl
│ ├─📂dto
│ ├─📂mapper
│ ├─📂remote
│ ├─📂repositoryImpl
│ ├─📂service
├─📂domain
│ ├─📂entity
│ ├─📂repository
├─📂presentation
│ ├─📂home
│ ├─📂main
│ ├─📂my
│ ├─📂search
│ ├─📂signIn
│ ├─📂signUp

2. 각 레이어 별 구성 요소 책임
core - 앱에서 공통적으로 사용하는 요소들을 넣었습니다. 화면 전반에서 쓰이는 공통 컴포넌트나 디자인 시스템 관련 파일을 넣었습니다.
data - 데이터와 관련된 코드를 담당하는 레이어입니다. API 호출이나 DB에 접근하여 상호작용합니다. 여기서 서버와 통신할 때 쓰이는 dto 데이터클래스 간에 mapping 코드나 서버 통신 시 필요한 코드들을 넣었습니다.
domain - 핵심 비즈니스 로직을 처리하는 레이어입니다. 이 레이어에서는 다른 레이어에 대한 의존성이 없어야 해서 Data나 Presentation에 독립적으로 동작해야합니다. 비즈니스 로직에서 필요한 entity들을 넣었습니다.
presentation - 사용자와 상호작용을 하는 레이어입니다. UI를 구성하는 요소와 관련 데이터들을 화면에 표시하며, 각 화면마다 폴더를 만들었습니다.

3. 아키텍처 패턴을 적용하며 어려웠던 점과 해결방법
거의 처음 아키텍처를 제대로 공부하고 적용해봐서 과제하는데 많은 시간이 걸렸습니다.. 각 계층별 책임 분리를 명확하게 하기 위해서 고려해야할 점들이 많았어서, 세미나 자료와 열심히 서칭을 해보면서 해결했던 거 같습니다. 기존 코드만으로는 아키텍처를 적용하기에 부족해서 책임 분리를 위해 새로운 파일들을 작성하며 과제를 완성했습니다. 처음 적용하기 어려웠지만, 아키텍처를 잘 이용하여 유지보수가 용이한 코드를 작성할 수 있도록 더 공부해보려고 합니다.

[imtaejugkim]

1. 클린 아키텍쳐

📦org.sopt.and
├─📂data
│  ├─📂local
│  ├─📂mapper
│  │  ├─📂todata
│  │  └─📂todomain
│  ├─📂remote
│  │  ├─📂datasource
│  │  ├─📂datasourceimpl
│  │  ├─📂model
│  │  ├─📂service
│  │  └─📂util
│  └─📂repositoryimpl
├─📂di
│   └─📂qualifier
├─📂domain
│  ├─📂model
│  ├─📂repository
│  └─📂type
├─📂presentation
│  ├─📂home
│  ├─📂login
│  ├─📂main
│  ├─📂mypage
│  ├─📂navigation
│  ├─📂search
│  └─📂signup
└─📂util

2. 각 레이어별 구성 요소 책임
   data: 실제 서버와 가장 가까운 역할로써, 통신 세팅 및 구현 관련 코드를 정의하고 서버의 데이터를 받아와 가공하는 역할을 합니다. 클린 아키텍쳐로써, domain으로 주입하는 코드가 포함되며 data에서 domain으로, 반대로 domain에서 data로 데이터를 매핑해주는 mapper가 포함됩니다.
   domain: 순수 kotlin언어로만 이루어진 비즈니스 레이어입니다. 앱에서 로직이나 핵심 데이터가 변경되는 경우, 해당 domain만 변경해서 수정할 수 있도록 구현하였습니다.
   presentation: UI를 담당하는 레이어입니다.

3. 어려웠던 점
   폴더와 파일들이 방대하여 처음에는 코드 하나하나 타고 들어가기 바빴습니다. 하지만 레이어 계층을 이해하고 구현하면서 데이터 전달의 흐름을 이해하게 되며 시야가 많이 넓어진 것 같습니다. 이렇게 책임분리를 통해, 재사용성이 좋아서 앞으로도 적극적으로 사용해보겠습니다.

[hyeeum]

𝟏. 여러분이 사용하신 아키텍처가 무엇이며 어떤 식으로 폴더링 하였는지를 정리해주세요.

클린 아키텍처

📂 App
┣ 📂 core
┃ ┣ 📂 component
┃ ┣ 📂 extension
┃ ┣ 📂 navigation
┣ 📂 data
┃ ┣ 📂 datasource
┃ ┣ 📂 datasourceimpl
┃ ┣ 📂 di
┃ ┣ 📂 dto
┃ ┣ 📂 repositoryimpl
┃ ┣ 📂 service
┣ 📂 domain
┃ ┣ 📂 entity
┃ ┣ 📂 repository
┃ ┣ 📂 usecase
┣ 📂 presentation
┃ ┣ 📂 home
┃ ┣ 📂 main
┃ ┣ 📂 my
┃ ┣ 📂 search
┃ ┣ 📂 signin
┃ ┣ 📂 signup

𝟐. 각 레이어 별 구성 요소의 책임이 무엇이라고 생각하며 아키텍처를 적용하셨는지 정리해주세요.

core - 여러 패키지에서 사용되는 코드
data - 서버 통신을 담당하는 레이어
domain - 앱의 로직,데이터을 정의하는(?) 레이어 <- domain을 바탕으로 data,presentation이 통신하기 때문에..?
presentation - 사용자가 보는 부분을 담당하는 레이어.

𝟑. 아키텍처 패턴을 적용할 때 본인이 중점적으로 생각하는 부분이나 신경쓰는 부분이 있다면 공유해주세요.

저는 domain layer가 다른 layer에 의존하지 않도록 많이 신경을 쓰는 것 같아요
Repository(domain layer)에서 서버통신과 관련된 함수를 정의하는데, 클린 아키텍처의 이론상 domain은 data layer에 의존되면 안되잖아요?
그래서 네이밍도 post/patch(get/delete는 흔히 사용되므로 제외함) 같은 서버통신에 종속적인 네이밍을 지양하는 편입니다..! <- 현업에서도 이렇게 신경쓰는 경우도 있다고 하네요..!

[hwidung]

1. 클린 아키텍처

📦org.sopt.and
├─📂data
│  ├─📂datasource
│  ├─📂datasourceimpl
│  ├─📂di
│  ├─📂mapper
│  ├─📂model
│  │  ├─📂request
│  │  └─📂response
│  ├─📂repositoryimpl
│  ├─📂service
├─📂domain
│  ├─📂entity
│  ├─📂repository
├─📂navigation
├─📂presentation
│  ├─📂ui
│  ├─📂viewmodel
│  ├─📂utils
└─📂ui.theme

2. 각 레이어 별 구성 요소의 책임

6주차 아키텍처 패턴

3. 신경쓰는 부분/어려웠던 점/해결한 경험

각 레이어 계층 간의 관계, 그리고 한 레이어 계층 내부에서 요소들의 관계를 이해하고 또 각각의 역할을 이해하는 것이 어려웠습니다.
그래도 세미나 예시처럼, 리팩토링을 하거나 다른 방식으로 확장할 때 이런 구현 방식을 사용하면 정말 좋겠단 생각이 들었습니다.

[jihyunniiii]

요기까지 필수 과제 마감!

[SYAAINN]

1. 적용 아키텍쳐 및 폴더링

• 적용 아키텍쳐 : 클린 아키텍쳐

📦org.sopt.and
├─📂data
│  ├─📂local
│  ├─📂mapper
│  │  ├─📂todata
│  │  └─📂todomain
│  ├─📂remote
│  │  ├─📂datasource
│  │  ├─📂datasourceimpl
│  │  ├─📂model
│  │  ├─📂service
│  │  └─📂util
│  └─📂repositoryimpl
├─📂di
├─📂domain
│  ├─📂model
│  ├─📂repository
├─📂presentation
│  ├─📂ui
│  │  ├─📂auth
│  │  ├─📂common
│  │  ├─📂main
│  │  ├─📂navigation
│  ├─📂util

2. 각 레이어 별 구성 요소의 책임

• data layer : local,remote 저장소로부터 앱에서 필요한 데이터를 끌어오고, presentation layer 에서 사용 가능하도록 가공해주는 역할
• di : dataSource, repository 등 의존성 주입을 위한 모듈들의 집합
• domain layer : 비즈니스 로직, 앱의 핵심을 담고 있는 layer. data layer와 presentation을 연결하면서 서로를 분리시켜주는 역할
• presentation layer : 화면의 생김새, 이동 등 사용자가 보게 되는 일체의 움직임들을 모두 담고, data layer가 받아온 data를 표시하는 역할

3. 아키텍쳐 패턴 적용 시 중점적으로 생각하는 부분, 신경 쓰는 부분

클린 아키텍쳐를 적용하는만큼 domain layer에 굉장히 신경을 많이 써야하지 않나 싶습니다.
특히 어떻게 하면 비즈니스 로직을 효율적이고도 일관성있게 담아낼지 model, type 등의 entity 설계에 신경을 많이 써야한다고 생각합니다.

(깜빡했습니다 ,,! 지각 제출 죄송합니다 😭)

[sayyyho]

1. 적용 아키텍쳐

클린 아키텍쳐

├─📂data
│  ├─📂datasource
│  ├─📂mapper
│  ├─📂model
│  │  ├─📂request
│  │  └─📂response
│  ├─📂repositoryimpl
│  ├─📂service
├─📂domain
│  ├─📂model
│  ├─📂repository
│  ├─📂usecase
├─📂presentation
│  ├─📂components
│  ├─📂navigation
│  ├─📂home
│  ├─📂myinfo
│  ├─📂search
│  ├─📂signin
│  ├─📂signup
│  ├─📂util
│  ├─📂viewmodelfactory
└─📂ui.theme

2. 각 레이어 별 구성 요소의 책임

Data 레이어는 서버 통신과 데이터 처리를 담당하며, DTO 매핑을 통해 데이터를 Domain으로 전달합니다.
Domain 레이어는 비즈니스 로직을 처리하며, 데이터 저장소와 상호작용하는 Repository 인터페이스를 정의합니다.
Presentation 레이어는 UI를 관리하고, ViewModel을 통해 Domain의 데이터를 받아와 화면을 업데이트합니다.
각 레이어는 독립적이며, 테스트 가능하고 의존성 분리가 이루어집니다.

3. 어려웠던 점

처음 클린 아키텍처를 적용하는 데 많은 시간이 걸렸습니다. 각 계층 간 책임 분리를 이해하고 구현하는 것이 어려웠고, 특히 코드의 흐름을 파악하는 데 시간이 많이 소요되었습니다. 하지만 결국 구조를 이해하고 책임을 분리하면서 코드 재사용성과 유지보수성이 높아졌음을 실감하게 되었습니다.

(토론 과제 미제출을 잊고 있었네요ㅠㅠ 오늘 확인해서 바로 제출했습니다.. 죄송합니다 🥹)