Swift ) Clean Architecture - EEYatHo iOS

 

 

Clean Architecture

---

• 개요
  
  여느 다른 아키텍처 패턴들 처럼,
  앱을 구성하는 여러 구성요소, 모듈들을 ( UI, ViewModel, Entity, Repository, DB 등 ) 바운더리치고 나눈 것.
  
  
  
• 바운더리의 기준
  
  
  • 자주 변경되는 모듈이, 거의 변경되지 않는 모듈을 의존하도록 하자!
    + 테스트 용이성.. 등등?
    
    
    • 변하지 않는 것을 안쪽으로, 자주 변하는 것을 바깥쪽으로 그림
    • 의존성을 바깥쪽에서 안쪽으로 주입 (바깥쪽이 변경되어도, 안쪽이 변경될 필요 없게. )
      
      
      • ex1. ) DataSource가 API를 써서 데이터를 받든, 로컬 DB의 데이터를 가져오든..
        안쪽의 Repository는 변경되지 않도록.
        
        
      • ex2. ) 반대로, 제일 안쪽의 Entity가 변경되었다면,
        DataSource의 Response DTO가 변경되어야 하고,
        Repository는 Response를 Entity로 변환하는 과정이 변경되어야 하고,
        ViewModel은 호출할 Usecase(비지니스 로직)이 변경되어야 하고,
        UI는 노출할 데이터가 변경되어야 한다.
        
        

PresentationLayer의 MVVM은 MVP, ReactorKit 등으로 변경될 수 있다

 

• 하지만 코드의 실행 흐름은, 의존 관계와 다르기 마련.
  
  
  • 일반적인 실행 흐름
    1. UI : 유저의 액션 수신, ViewModel에게 명령
    2. ViewModel : UseCase에게 비지니스 로직 요청
    3. UseCase : Repository에게 비지니스 로직에 필요한 데이터 요청
    4. Repository : DataSource(Network, DB 등)에게 데이터 요청
    5. DataSource : Repository 에게 Response(DTO) 반환
    6. Repository : Response를 Entity로 변환하고 UseCase에게 반환
    7. UseCase : ViewModel에게 반환
    8. ViewModel : UI 업데이트
    
    
    
  • 3, 4번에서 의존성 역전이 필요하게 된다.
    ( 실행 흐름과, 의존 방향이 반대 )
    ( UseCase가 Repository에 접근해야하는데, Repository 구현체를 몰라야한다. )
    

 

• 의존성 역전하기
  
  
  • 3. UseCase는 Repository의 Interface(protocol) 을 가지고 요청한다.
  • 4. Repository는 DataSource의 Interface(protocol) 을 가지고 요청한다.
    
    
  • 3-1. 그렇다면, Repository의 protocol은 어디에 있어야하는가? UseCase? Repository?
    
    
    • UseCase이다.
      Repository에 어떤식으로 접근할건지까지 UseCase 본인이 정해야한다.
      그래야 Repository에게 의존되지 않은 것이니까.
      
      
    • import 관련
      
      • Repository, UseCase를 Project단위로 모듈화하고 import 하는 형태라면, (단순 폴더링이 아니라면,)
        Repository도 protocol을 채택하고 구현해야하기 때문에, Repository protocol을 알고 있어야한다.
      • UseCase에 있는 protocol을 알기 위해서, Repository가 UseCase 전체를 import하는 것을 불필요해 보인다.
        또 한 Repository에 접근하는 protocol을 여러 UseCase가 가지고 있는 것도 당연히 이상하다.
      • 이를 해결하기 위해 Interface 모듈을 두고, UseCase와 Repository가 각각 import 하게하면 해결된다.

 

 

 

• UseCase -> Repository 만 의존성 역전하면 된다..?
   
  • 몇몇 글들을 보면 UseCase -> Repository 에서만 의존 역전이 필요하다고 설명한다.
    Repository -> DataSource 는 같은 Layer 라서 의존 역전이 필요없는 듯한 그림들이 널려있다.

UseCase -> Repository 에서만 의존성 역전을 하는 그림들.

 

 

 

• 어쩌다 그렇게 됐는진 모르겠지만, 클린 아키텍쳐 원문을 보면 그렇지 않다.
  
  
  • 초록색 영역을 Interface Adapters 라고 칭하며, 외부에서 들어온 데이터를 Entity로 변경하는 Repository를 설명하고있고,
  • 파란색 영역을 프레임 워크나 DB를 칭하며 DataSource 를 설명하고 있다.
  • 그리고 소스 코드 종속성은 안쪽으로만 향한다 Dependency Role 로써, 초록색, 파란색 영역을 명확하게 나누었다.
  • Layer 이 왜 갑자기 나온것이며, Layer으로 나눈 아키텍쳐 패턴은 뭐라고 불러야 하나..?  
  • 이 글 때문인가..

 

 

•