Clean Architecture

Clean Architecture

Clean Architecture란?

클린 아케틱처는 Uncle Bob이 2012년 엔터 프라이즈 아키텍처에서 논의 되던 내용을 집약 시킨 개념이다.
클린 아키텍처는 두가지 관점에서 볼 수 있다.

• 1. 아키텍처 설계의 철학과 원칙
     • SOLID원칙을 중심으로 SW설계에서 중요하게 거론되어온 다양한 원칙들을 일목요연하게 정리한다.
• 2. 과녁 그림으로 유명한 아키텍처의 청사진.
     • 
     • 이는 Hexagonal Architecture, Onion Architecture 등 당시 널리 알려진 아키텍처들의 공통된 설과물을 정리한것이다.
     • 모바일 부터 백엔드 까지 모든 소프트웨어에 일반적으로 필요한 내용을 담고 있으며, 각 계층을 어떻게 나누고 어떤 요소로 구성할 것인가에 대한 원칙들을 알려준다.
     • 가운데로 갈 수록 높은 수준, 바깥으로 갈 수록 낮은 수준의 컴포넌트로, 이에 대한 효율적인 분리로 효과적인 설계가 가능하다는 점을 성명한다.

클린 아키텍처는 2018년에 책으로 정리되어 출간 했지만, 그전부터 이미 아키텍처 분야에서 가장 많이 거론되었으며 다양한 SW의 설계에 영감을 주었다.

모바일 관점에서는 아래 네가지 부분에서 큰영향을 준다.

• 1. 경계선(Boundaries): 계층 구조의 개념이 널리 적용된다.
• 2. 유스케이스(Use Case): 도메인 계층의 분리로 소스코드 변경 안정성(Stability)이 높아진다.
• 3. 험블 객체(Humble Object): 프리젠테이션 계층의 테스트 가능성, 가독성, 유지 보수성을 향상한다.
• 4. 의존성 역전(DIP): modular한 프로젝트 구조의 확산

경계선 계층 나누기

소프트웨어 아키텍처는 선을 긋는 기술이며, 나는 이러한 선을 경계(Boundary)라고 부른다.
경계는 소프트웨어 요소를 서로 분리하고,
경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다.
- Robert C. Martin, Clean Architecture Ch.17

클린 아키텍쳐는 세개의 계층으로 분리 하며 다음의 그림과 같이 계층을 분리한다.

Presentation Layer

화면의 표시, 애니메이션, 사용자 입력 처리등 UI에 관련된 모든 처리를 갖는다.

• View:

  • 직접적으로 플랫폼 의존적인 구현, 즉 UI화면 표시와 사용자 입력만 담당한다.
  • 자기가 화면에 그리는 것이 어떤 의미가 있는지는 전혀 알지 못하고, 다만 프리젠터의 명령을 받아 화면을 어떤 이미지, 어떤 색깔로 그릴까를 결정할뿐이다.
  • 주의할점은 View가 꼭 ViewController만을 의미하지는 않는다는것이다.

• Presenter:

  • 단순히 MVP/Viper 에서의 프리젠터만을 의미하는 용어가 아니라 넓은 의미의 단어로 생각하면된다.
  • 예를 들어 MVVM 구조에서 ViewModel과 동일한 의미로 생각 할 수 있다.
  • 프리젠터는 뷰와 달리 플랫폼에 직접적으로 의존하지 않는 클래스다.
  • 손쉽게 단위 테스트가 가능하며 프리젠터는 뷰와 달리 화면에 그리는것이 어떤 의미를 가지고 있는가를 알고 있다.
  • 사용자 입력이 왔을 때 어떤 반응을 해야하는지에 대한 판단도 프리젠터가 한다.

Domain Layer

• UseCase:
  • 비즈니스 로직이 여기에 구현된다.
• Model:
  • 앱의 실질적인 데이터가 여기에 구현된다.
  • 도메인 모델은 REST API등으로 얻어지는 외부 데이터와 같을 필요 없다.
• Translater:
  • 데이터 계층의 엔티티 - 도메인 모델을 변환하는 mapper의 역할을 한다.

DataLayer

• Repository:
  • 관점에 따라 도메인 계층 소속일 수도 있고, 데이터 계층 소속일수도 있다.
  • UseCase가 필요로 하는 데이터 저장/수정 등의 기능을 제공하는 클래스다.
  • 데이터 소스를 인터페이스 형태로 참조하기 때문에 이클래스에서 데이터 소스 객체를 갈아끼우는 형태로 외부 API호출/ 로컬DB접근/ Mock Object 출력을 전환할 수 있다.
• DataSource:
  • 실제 데이터의 입출력이 여기서 실행된다.
• Entity:
  • 데이터 소스에서 사용되는 데이터를 정의한 모델로, 맨위의 과녁 그림에서의 엔티티와는 다른 개념이다.
  • REST API의 요청/응답을 위한 JSON, 로컬DB에 저장하기 위한 테이블이 대표적이다.

Domain Layer의 UseCase와 Presentation Layer의Presenter 는 어떻게 구별할까??

대부분의 경우 UseCase의 비즈니스 로직과 Presenter의 로직은 명확히 구별되지만 가끔 헷갈리는 경우가 있다.

이를 구별하는 가장 좋은 질문은 "개발팀 외부의 사업 부서의 사람도 알고 있어야 하는 로직인가?" 이다.
비즈니스 로직은 문자 그대로 앱의 사용자 상호작용이 아닌 업무 요구사항을 담고 있는것이기 때문이다.

계층을 나누었을때의 이점

이렇게 계층을 분리함으로 인해 얻을수 있는 가장큰 이점은 분량이 많은 앱이더라도 소스코드 전반을 쉽게 장악할 수 있다는 점이다.

복잡한 수정 사항이 생겼을 때라도 어떤 부분들을 고치면 되는지 금방 파악할 수 있다.
모듈 구성, 그리고 패키지/ 폴더 구성이 자연스럽게 각 계층별로 일목요연한 트리구조를 이루기 때문에 다른 개발자나 혹은 몇달뒤의 내가 다시 코드를 들여봐도 금방 코드를 이해하고 수정할수 있다.

지금 수정할필요가 없는 코드를 보지 않고도 필요한 부분만 보면된다.
그리고 무엇보다 좋은점은, 특징 계층에 대한 수정이 다른 계층에 거의 영향을 주지않는다는 것이다.

부작용

클린 아키텍처는 많은 장점이 있는 반면, 부작용으로 간단한 로직을 구현할 때도 상당히 많은 양의 클래스를 만들어 줘야 한다는 부담이 있다.
딱히 비즈니스 로직이랄것이 많이 갖고 있지 않는 앱이라면 애초에 클린 아키텍처의 모든 측면을 일일히 구현할 이유가 없다.

이를 해결할 방법으로 몇가지 대안을 생각해볼수있다.

• 1. 요소들 통합하기
     • 예를 들자면 DataSource와 Repository를 통합 할수 있다.
     • 데이터 패턴이 단순 하다면 Repository와 DataSource클래스를 통합하는 것도 좋은 방법이다.
     • 또는 Repository를 실제로는 인터페이스(혹은 프로토콜)만 갖도록 정의하고, 그 구현 클래스가 데이터 소스 역할을 하는것도 즐겨 사용되는 방법이다.
• 2. 필요없는 요소 축약하기
     • 예를 들면 UseCase 생략이 있다.
     • 앱에 비즈니스 로직이 거의 없는경우 프리젠테이션 계층과 데이터 계층 사이의 중계만을 위해 단순한 내용의 UseCase를 만든 경우 비즈니스 로직의 양이 많지 않은 경우라면 굳이 UseCase를 만들기 보다는 일부는 레포지토리로, 일부는 프리젠터로 흡수시켜도 된다.
• 3. 기능 최적화 문제
     • 클린 아키텍처 적용으로 많은 클래스가 추가되어도 객체 숫자로 인한 성능과 메모리의 손실은 상당히 미미하다.
     • 하지만 트랜스레이터에서의 변환 과정은 데이터 량이 많을 경우 무시 못할 성능 저하를 가져올수 있다.
     • 예를 들면 URL 파싱과 같은 처리가 변환 과정에서 필연적으로 일어나는 경우를 생각할 수 있다.

참고한 문서및 자료

https://medium.com/@justfaceit/clean-architecture%EB%8A%94-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EA%B0%9C%EB%B0%9C%EC%9D%84-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%84%EC%99%80%EC%A3%BC%EB%8A%94%EA%B0%80-1-%EA%B2%BD%EA%B3%84%EC%84%A0-%EA%B3%84%EC%B8%B5%EC%9D%84-%EC%A0%95%EC%9D%98%ED%95%B4%EC%A4%80%EB%8B%A4-b77496744616
https://tech.olx.com/clean-architecture-and-mvvm-on-ios-c9d167d9f5b3