클린 아키텍처 (iOS 전용 포함)

설명

• 목적은 관심사의 분리
•  각각의 레이어마다 관심사가 분리된 채 본인의 역할에 집중하도록 설계함에 따라,
  • 유지보수 시, 변경이 필요한 레이어만 확인하면 되므로 코드의 가독성과 유지보수성이 높음
  • 독립적으로 다른 레이어와 분리된 채 테스트 가능
  • 독립적이기에 하나의 레이어가 다른 여러 레이어들에서 재사용될 수 있어 재사용성이 높음
• 레이어는 1. 비즈니스 규칙을 위한 계층과 2. 인터페이스를 위한 다른 계층이 존재
• 클린아키텍처는 다음과 같은 시스템을 생성함
  • 프레임워크에 독립적: 클린아키텍쳐는 소프트웨어 라이브러리에 의존하지 않음
  • 테스트에 용이함: UI, DB, 웹서버, 외부요인없어도 테스트 가능
  • UI가 독립적인 시스템: 다른부분 수정없이 UI변경이 가능
  • 데이터베이스가 독립적인 시스템: 데이터베이스를 변경하기 쉬움
  • 외부기능으로부터 독립적인 시스템

의존 규칙

• 원들은 각각 다른 레이어를 나타내는데, 안쪽으로 갈수록 고수준임
  • 고수준에 대해 2가지 의견 나뉨
    1. 추상화 정도를 기준으로는, 고수준은 추상화된 개념, 저수준은 실제 구현체
    2. 비즈니스 로직을 담고 있느냐를 기준으로는, 고수준은 가지고 있고 저수준은 가지지 않음
• 의존성 방향은 안쪽으로 향함
  • 안쪽의 원들은 바깥 원들은 전혀 모름, 따라서 바깥원의 영향을 받지 않아 유지보수성이 좋아짐

Entity

• 서비스의 코어한 부분의 데이터와 이 데이터를 처리하는 비즈니스 로직이 있을 것임
  • 이 둘을 합쳐 Domain 레이어라함
  • 핵심적인 부분의 데이터가 Entity고 비즈니스 로직이 아래 설명할 UseCase
• 변경될 가능성이 가장 적은 부분으로 다른 계층과 의존성이 생기면 안됨

UseCase

• Domain 레이어로써 비즈니스 로직을 담당
• UseCase가 변해도 Entity에 영향을 미치면 안됨
• 외부 프레임워크가 바뀌든, 데이터를 저장한 DB가 어디든 간에 UseCase는 영향을 받지 않음

Interface Adapters

• 이 계층에 데이터가 들어오면 Entity나 UseCase에서 사용하기 쉬운 형태에서 DB, 웹서버와 같은 외부 프레임워크에 사용하기 쉬운 형태로 변환되는 곳
• Entity를 사용자에게 보여주기 위해 전처리 되고 보여주는 단계
  • MVVM의 ViewModel에 해당됨
• DB, 웹서버 등과 같은 외부 프레임워크는 Interface Adapters 레이어까지만 알아야함. Domain 레이어에 대해서는 알면 안됨

Frameworks and Drivers

• DB, Web, Device, UI, External Interfaces가 담겨있음
• UI를 담당하는 View도 이곳에 해당
• 이 레이어는 보통 프레임워크나 도구로 구성됨 (예를들어 데이터베이스나 웹 프레임워크)
• 안쪽 원과 통신할 연결코드 외에는 별다른 코드가 없음
• 변경이 잦은 부분!

경계 넘어가기

• 그림 우측 하단에는 어떤식으로 원의 경계를 넘을 수 있는 지 보여줌
• Controller와 Presenter가 UseCase와 어떻게 대화하는지 보여줌
• 흐름은 Controller에서 UseCase를 거쳐서 Presenter에서 실행되고 있는 흐름인데, 의존성은 모두 UseCase방향이란것이 중요
• 흐름과 의존의 방향이 역방향으로 구현하는데는 의존관계 역전 원칙(DIP)으로 해결함
  • UseCase가 Presenter를 호출해야할 때, 의존성 규칙으로 바깥원을 호출할 수 없으므로, UseCase는 안쪽에 있는 Interface(Use Case Outer port라고 적혀있는)를 호출함. 그리고 원 바깥쪽의 Presenter는 이 인터페이스를 구현함

---

iOS 설계에서의 클린아키텍처

모바일 설계에서 클린 아키텍처를 적용하기 위한 방법 중 하나로, 3Layer형태로 사용함

3Layer형태

1. Domain Layer
   • Entity와 UseCase을 묶어 Domain 레이어라 함
   • 서비스의 코어한 부분의 계층
   • Entity - 앱의 코어 데이터
   • UseCase - Entity를 처리할 비즈니스 로직
2. Presentation Layer
   • UI표시, 애니메이션, 이벤트 핸들링 같은 UI관련 모든 처리를 담당
   • View
     • UI화면 표시와 사용자로부터 UI이벤트를 수신함
     • 사용자로 부터 상호작용 이벤트가 일어나면 이에 대한 로직 처리를 Presenters에 요청
     • Data Binding을 통해, Presenters의 데이터를 관찰하고 있다가 해당 데이터가 변화가 있다면, 직접 해당 데이터에 대한 UI를 자동으로 변경시킴
     • View가 직접 본인의 Life Cycle이나 사용자와의 상호 작용 이벤트를 관리함
   • Presenters
     • MVP/VIPER 라면 Presenter역할, MVVM이라면 ViewModel의 역할과도 같음
     • View로 부터 전달받은 요청을 해결할 로직을 담고 있음
     • 데이터 변화에 대해 View에게 Data Binding을 통해 notification을 줌
3. Data Layer
   • 통신 및 데이터 관리 로직을 담당
   • Repository
     • UseCase가 필요로 하는 데이터를 관리(CRUD)함
   • DataSource
     • DataSource는 보통 외부 시스템(데이터베이스, API 등)에 대한 접근을 처리하는 바깥쪽 계층에 위치함
     • 데이터베이스, 파일 시스템, 외부 API 등과 같은 실제 데이터 저장소와 상호작용하는 책임
     • DTO
       • DTO는 DataSource에서 사용되는 데이터를 정의한 타입
         • ex) 웹서버의 Request/Response을 위한 JSON, 로컬 DB에 저장하기 위한 타입들
       • DTO타입을 Domain 레이어에서 사용하는 Entity 타입으로 변환해서 사용해야 할텐데, 이 역할을 Mapper(Translater)가 담당함

의존성 규칙

• Presentation 레이어와 Data 레이어가 Domain레이어를 바라보는 의존성 방향이 지켜져야함
• 의존성 역전
  • Domain 레이어에서 Data 레이어 방향으로 향하면 안되는데, 위 그림을 보면 Domain 레이어에서 Data 레이어를 소유한채 데이터를 가져오는 것 처럼 보임 → 의존성 역전 방법을 통해, 즉 Repository를 인터페이스로 만들고 Domain 레이어가 이 인터페이스를 참조하게 하는 것임

현업에 적용하며 개인적으로 느낀점

• 신규 기능 개발 시, 기존 MVC형태가 아닌 클린아키텍처로 적용했다. 폴더 구조부터 각각의 레이어들을 새롭게 작성하는 공수가 만만치 않았다.(살짝 현타왔었음..) 또한 레이어마다 테스트코드를 작성하는 것도 부담으로 다가왔다. 영혼을 갈아 넣어 첫 대규모 기능에 클린아키텍처를 적용하고 기존 코드도 리팩토링을 이어나갔다.
  그 뒤 시작된 다음 기능 개발에서 이전에 작성했던 클린아키텍처의 레이어들이 재사용되기 시작했다..(감격) 데이터 레이어 코드는 다수의 도메인 레이어에서 사용됐고, 무엇보다 이전에 작성했던 도메인 레이어 UseCase들이 재사용될때의 시간 절약은 나의 워라벨을 지켜주었다.. 1차 기능 개발때는 클린아키텍처 때문에 더 많은 공수가 소요되었지만, 그것들이 소중하게 모여 2차 기능 개발때는 공수를 덜어주는 고마운 녀석들로 다가왔다.

 

참고

https://zeddios.tistory.com/1065

https://sunny-maneg.tistory.com/entry/클린아키텍쳐Clean-Architecture

https://sunny-maneg.tistory.com/entry/iOS-설계에서의-Clean-Architecture