UniDirectional Data Flow 및 Single source of truth 개념 정리

[lminsu]

Single Source of truth

• 앱에 새로운 data type이 정의되면, 그 data type에 single source of truth를 할당해줘야 한다.
• SSOT는 data의 owner이다. 오직 SSOT만이 이것을 수정할 수 있다.
• SSOT는 data를 immutable type으로 제공해야한다.(다른 곳에서 수정 못하게)(프로퍼티 val로 선언하라는 뜻으로 추측됨)
• SSOT는 해당 data type의 인스턴스를 제공하는 함수를 제공하거나, 이벤트를 전달 받음으로서 data를 수정할 수 있다.(예를 들어 onClickButton() 같은)

이런 패턴은 아래와 같은 장점들을 가져온다.

• 한 공간에 그 타입에 대한 모든 변경들을 모을 수 있다.
• 다른 클래스가 그것을 손상시킬 수 없도록 보호한다
• 데이터의 변경을 더 추적하기 쉽게 만든다.(SSOT 한 곳만 보면 되므로) → 버그를 더 쉽게 찾을 수 있다.

offline-first application(앱 첫 시작 때 네트워크를 통해 데이터를 불러오지 않는 앱)의 경우, 앱 데이터의 SSOT는 보통 데이터베이스이다. 다른 경우에 SSOT는 뷰모델이나 심지어 UI가 될 수도 있다.

Unidirectional Data Flow

• UDF에서 state는 한 방향으로민 흐르고, event는 그 반대 방향으로 흐른다.
• 예를 들어, 앱 데이터는 보통 data source에서 ui로 흐른다. → dataSource부터 위로 올라가면서 앱 데이터를 만들어가며 전달한다.
• 버튼 클릭과 같은 사용자 event는 UI에서 SSOT로 흐르며, SSOT에서는 앱 데이터를 수정하고 앱 데이터를 immutable type으로 제공한다.

Recommended app architecture

위에서 설명한 내용들(SSOT, UDF)을 따르려면 최소한 두 개의 layer가 존재해야 한다.(UI 레이어, data 레이어)

• UI Layer는 앱 데이터를 screen에 보여준다
• data layer는 비즈니스 로직을 포함하고 앱 데이터를 제공한다
• UI와 data layer 사이의 상호작용을 간단하게 하고, 재사용하기 위해 domain layer를 추가할 수도 있다.

• 위 그림에서 화살표는 클래스들 간의 의존성을 의미한다. 예를 들어서, domain layer는 data layer 클래스들에 의존한다.

UI layer

UI 레이어는 아래 두 개로 이루어져 있음

• 데이터를 화면에 그리는 Ui 요소(뷰)
• 데이터를 가지고 있고, 그 데이터를 UI에 제공하고, 로직을 처리하는(?) state holder(뷰모델 같은)

Data Layer

• 데이터 레이어는 비즈니스 로직을 포함하고 있음, 비즈니스 로직이란 어떻게 앱이 데이터를 생성하고 저장하고 변경하는지에 대한 내용
• 데이터 레이어는 repository로 이루어져 있고 각각의 repository는 0부터 여러 개의 data source를 가지고 있음
• 앱에서 데이터를 다루는 각각의 타입마다 repository 클래스를 생성해야 함
• 예를 들어, 영화와 관련된 데이터를 위한 MoviesRepository 또는 결제와 관련된 데이터를 담당하는 PaymentsRepository가 있을 수 있음
• repository 클래스는 아래와 같은 역할을 함
  • 앱의 나머지 부분에(데이터 레이어를 제외한) data를 제공함
  • 데이터에 대한 변화가 집중되어 있음
  • 여러 dataSource 간의 충돌을 해결함
  • 하나의 dataSource 클래스는 하나의 data source에만 관련이 있어야함(예를 들어, 로컬 데이터베이스나 네트워크 통신 같은)
  • dataSource 클래스는 앱과 시스템(데이터 조회, 삽입 같은 데이터 연산) 간의 브릿지 역할을 함
  • 앱의 나머지 부분에게 data source를 추상화함(앱의 나머지 부분은 dataSource에 대해서 몰라도 됨)
  • repository 클래스를 사용하는 쪽에서는 repository 클래스의 data source가 바뀌어도 모름
  • 비즈니스 로직을 포함함

[lminsu]

UDF의 장점

단방향 의존성의 장점

• 단방향 의존성이란?
  • 뷰(프래그먼트)에서는 뷰모델 클래스를 참조, 뷰는 뷰모델을 앎
  • 뷰모델에서는 뷰 클래스 참조 없음, 뷰모델은 뷰를 모름
• 단방향 의존성의 장점
  • ⚠️뷰가 바뀌어도 뷰모델 코드의 수정 없음
  • 예를 들어, 아래와 같은 상황일 떄 뷰만 수정하고, 뷰모델은 수정하지 않아도 된다는 장점이 있음
    • 뷰모델에 a 데이터 존재, 뷰에서 a 데이터를 사용하는 뷰가 바뀜(A에서 B로)
    • a 데이터를 a 텍스트뷰에 바인드하는 것에서, b 스낵바로 노출하는 것으로 바뀐다면?
  • 서로 의존성이 있을 때(뷰모델이 프래그먼트가 제공하는 함수를 사용하여 데이터를 바인드하는 경우)
    • 뷰모델에서 프래그먼트의 bindAView()함수를 호출하는 것 대신 bindBView() 함수를 호출하도록 변경해야 함
  • 뷰→뷰모델으로만 의존성이 있을 때
    • 프래그먼트에서 어떤 수정이 발생하더라도 뷰모델에서는 프래그먼트를 참조하고 있지 않기 때문에 뷰모델은 수정 없음
  • 위의 예시는 단편적인 예시이고 중요한 것은, 뷰모델에서 뷰를 참조하고 있으면 ⚠️뷰가 수정될 때 뷰모델이 수정될 가능성이 존재한다는 것
  • 예를들어, 뷰가 제공하는 메서드가 변경된다던가, 프래그먼트 이름이 바뀐다던가, 뷰 로직이 변경된 경우
  • 개념적으로, 뷰는 뷰모델을 사용하는 쪽이고 뷰모델은 사용 당하는 쪽인데, 사용하는 쪽이 수정되었다고 사용 당하는 쪽에서 수정이 일어나는 것은 불필요함

    state를 분리하는 것의 장점(관심사 분리)

• state 분리(관심사 분리)란?
  • state를 관리(저장, 수정 등)하는 곳과 사용하는 곳을 분리
  • 뷰모델: state를 관리하는 곳
  • 뷰: state를 사용하는 곳
• state 분리 안 함의 단점(state를 관리하는 곳과 사용하는 곳이 분리가 되지 않았다면)
  • state 관리 로직은 그대로고 뷰 로직만 변경될 때, ⚠️state를 관리하는 로직을 안 건드리도록 주의하면서 뷰 로직을 변경해야 함
  • 예를 들어, a 프래그먼트가 보여주는 데이터는 동일한데, 그 데이터를 보여주는 뷰의 배치가 완전히 새롭게 변경되었다고 하면
  • 보여주는 데이터는 그대로고 뷰의 배치만 바뀌으므로, 뷰로직만 변경되도록 주의하면서 개발해야함
  • 마찬가지로, 뷰 로직은 그대로고 state를 관리하는 로직만 변경되었을 때도, 뷰 로직을 안 건드리도록 주의하면서 state 관리 로직을 변경해야 함
  • 예를 들어, a 데이터에 새로운 validataion 로직이 추가되었다고 하면
    • 사용자가 입력한 텍스트에 최소 몇 문자 조건만 있다가 특수문자 포함 조건이 추가된 경우
  • 단순히 state에 validataion 추가 로직만 넣는 것이므로 뷰로직은 건들지 않도록 주의하면서 개발해야 함
• ⚠️ 클래스별로 관심사 분리가 되어있다면, 어떤 로직이 변경될 때 그 로직과 관련된 클래스만 변경하면 됨

[lminsu]

SSOT의 장점

• 공식 문서에 있는 나와있는 장점들
  • 한 공간에 그 타입에 대한 모든 변경들을 모을 수 있다.
  • 다른 클래스가 그것을 손상시킬 수 없도록 보호한다
  • 데이터의 변경을 더 추적하기 쉽게 만든다.(SSOT 한 곳만 보면 되므로) → 버그를 더 쉽게 찾을 수 있다.
• ⚠️ SSOT는 어떤 데이터의 생성 및 수정을 한 클래스에서만 하도록 강제하는 것
  • 데이터의 생성 및 변경이 일어나는 곳이 한 클래스(A 클래스)에 고정되있다면, 다른 클래스에서 A 클래스에서 제공된 인스턴스를 사용할 때,
  • A 클래스에서 제공된 인스턴스 그대로 사용되고 있음을 확신한 채로 디버깅 가능
  • 여러 군데에서 데이터의 생성 및 변경이 일어난다면, 생성 및 변경이 일어나는 곳마다 분기를 생각하며 디버깅해야 함
  • 예를 들어, A 클래스의 a 메소드에서만 데이터의 생성 및 수정이 일어난다면
  • a 메소드가 호출되어 생성된 인스턴스는 여러 클래스에 전달되며 사용되더라도, 값이 바뀌지 않을 것임이 확실함
  • 이와 달리, A 클래스의 a 메소드 뿐 아니라, B클래스의 b 메소드에서도 데이터의 생성 및 수정이 일어난다면
  • 어떤 클래스에서 사용되는 데이터가 두 메소드의 중 어느 곳에서 사용된 것인지 확인 해야 함
  • a 메소드에서 생성된 인스턴스와 b 메소드에서 생성된 인스턴스 중 어느 것을 사용할지 결정해야 함
  • a 메소드에서 생성된 인스턴스와 b 메소드에서 생성된 데이터를 일치시켜 사용해야 한다면, 이에 해당되는 추가 로직이 필요함

[lminsu]

MovieRepository 클래스와 TmdbMovies 클래스의 의존성에 대한 생각

• 배경
  • tmdb api를 호출하여 TmdbMovies 인스턴스를 얻음
  • TmdbMovies 인스턴스를 List\<Movie> 인스턴스로 변환하여 사용해야 함
• 고민한 포인트
  • TmdbMovies 인스턴스를 List\<Movie> 인스턴스로 변환하는 함수를 어디에 정의할 것인가 1) TmdbMovies 클래스, 아래 코드 예시에서 makeMovies() 2) MovieRepository 클래스. 아래 코드 예시에서 toMovies()

• TmdbMovies 클래스에 정의한 경우 코드는 아래처럼 구현됨

  • MovieRepository 클래스에서 remoteDataSource로부터 TmdbMovies 인스턴스를 받고, makeMovies() 함수를 호출함
  • 이에 대응되는 의존성은 아래와 같이 구성됨
  • 
  • 문제점1: Movie 클래스의 single source of truth가 TmdbMovies 클래스가됨(MovieRepository가 아니라)
  • 문제점2: TmdbMovies 클래스가 Movie 클래스를 의존함
  • → TmdbMovies 클래스는 Movie 인스턴스를 만들 때 재료가 되는 클래스이므로 Movie가TmdbMovies를 의존해야지, 그 반대가 되어서는 안 됨
  • → Movie 클래스의 프로퍼티가 바뀌었다고 TmdbMovies 클래스가 수정되어서는 안 됨
  • 반대로, TmdbMovies 클래스의 프로퍼티가 바뀌어서 Movie 클래스가 수정되는 것은 괜찮음
  • ⚠️사용하는 쪽이 변경되었다고, 사용 당하는 쪽이 변경되어서는 안 됨⚠️
  • 라이브러리를 예시로 생각해보면, 앱이 변경되었다고 그 앱에서 사용하고 있는 라이브러리에서 수정이 일어나서는 안 된다는 말임
  • 라이브러리가 변경되었으면, 당연히 그 라이브러리를 사용하는 앱은 변경이 일어날 수 있음. 하지만, 그 반대는 안 됨
  • 만약 앱이 변경될 떄 라이브러리의 수정이 필요하도록 설계되어 있다면 아래와 같은 문제가 일어 날 수 있음
    • A, B 앱이 동알한 라이브러리를 사용하고 있는 상황
    • A가 수정될 때 B도 같이 수정이 필요해짐(A 수정 → 라이브러리 수정 → B 수정)

  • 만약 라이브러리에서 A(또는 B)에 대한 의존성이 없었다면?

    • A가 수정되었다고 해서 B가 수정되는 일은 발생하지 않음

      
      class MovieRepository {
      private val remoteDataSource: RemoteDataSource = RemoteDataSource()

    suspend fun getMovies(): List? { return remoteDataSource.getTmdbMovies()?.makeMovies() } }

  data class TmdbMovies( val page: Long?, val results: List?, ) { fun makeMovies(): List? { return results?.map { tmdbMovie -> Movie( tmdbMovie.id ?: return null, tmdbMovie.title, tmdbMovie.overview, tmdbMovie.releaseDate, tmdbMovie.makePosterPathWithBaseUrl() ) } } }

• MovieRepository 클래스에 정의한 경우

  • 이에 대응되는 의존성은 아래와 같이 구성됨
  • 

  • TmdbMovies 클래스의 Movie 클래스 의존성을 제거할 수 있음

    
    class MovieRepository {
    private val remoteDataSource: RemoteDataSource = RemoteDataSource()
    
    suspend fun getMovies(): List<Movie>? {
      return remoteDataSource.getTmdbMovies()?.toMovies()
    }
    
    private fun TmdbMovies.toMovies(): List<Movie>? {
      return getTmdbMovies()
          ?.map { it.toMovie() }
          ?.filterNotNull()
    }
    
    private fun TmdbMovie.toMovie(): Movie? {
      return Movie(
          id = id ?: return null,
          title = title,
          overview = overview,
          releaseDate = releaseDate,
          posterPath = makePosterPathWithBaseUrl()
      )
    }
    }

  data class TmdbMovies( val page: Long?, val results: List?, ) { fun getTmdbMovies(): List? { return results } }