Clean Architecture

Clean Architecture란

Robert C.Martin(Uncle-Bob)분이 블로그에 올린 아키텍처 중 하나이다.

프레임워크의 독립성, testable, UI의 독립성, Database의 독립성, 외부 로직에 대한 독립성 등 

이런 여러 아키텍처의 장점을 하나로 모은 Clean Architecture를 만들어 소개

Clean Architecture Diagram

Dependency Rule

외부 원으로부터 화살표가 안으로 향하는 모습을 볼 수 있다.

바깥쪽일수록 상위모듈의 특성이고 안쪽일수록 하위 모듈의 특성을 가진다.

Clean Architecture에서 중요시 하는 부분 중 하나가 화살표가 상위 모듈부터 안쪽인 하위 모듈만 의존하는 규칙이다.

안쪽의 모듈들은 바깥쪽의 모듈에 대해 어떤한것도 알 수 없다.(참조할 수 없다)

FrameWorks and Drivers

가장 바깥쪽의 계층은 데이터 베이스나 웹프레임워크등 일반적으로 프레임워크나 도구로 구성된다.

이 계층은 안쪽의 원과 통신하는 코드 이외에는 별다른 코드가 존재하지 않는다.

Interface Adapters

이 계층의 소프트웨어는 어댑터의 집합이다. 이는 유스케이스와 엔티티에 있어 용이한 형식으로부터

데이터베이스나 웹 등 외부의 기능에 용이한 형식으로 데이터를 변환한다. 

데이터는, 엔티티나 유스케이스에 용이한 형에서, 사용하고 있는 프레임워크에 용이한 형으로 변환된다.

Usecase

비지니스 로직을 담당

엔티티로부터 또는 엔티티로의 데이터 흐름을 조합한다.

데이터베이스나 UI 또는 공통 프레임워크의 변경으로부터 영향을 받지 않는다.

Entity

가장 안쪽의 원으로 하위 모듈을 의미한다.

대규모 프로젝트 레벨의 비지니스 규칙을 캡슐화한다.

바깥쪽에서 어떠한 변경이 일어나도 영향을 받지 않는다.

iOS 클린 아키텍처

출처: https://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc

Presentation Layer

• UI의 표시나 이벤트의 처리를 실시합니다, 비즈니스 로직 처리는 하지 않는다.

View (ViewController)

 

• 화면 표시 및 사용자 터치 이벤트 등의 이벤트를 Presenter에 알림
• Presenter에서받은 Model의 데이터와 상태에 따라 View의 표시를 전환

Presenter

 

• View에서 이벤트를 받고 필요한 경우 이벤트에 따라 UseCase 실행
• UseCase에서 받은 데이터를 View로 전달
• View가 무엇인지 모른다.

 

---

Domain Layer

• iOS 애플리케이션 종속 비즈니스 로직은 이 레이어가 담당

UseCase

 

• 유스 케이스에 필요한 로직 처리를 기술한다.
• 어떤 데이터를 받아올지 구현
• UI에는 직접 관여하지 않는다 (View, ViewController에서 직접 참조되지 않음)

Translater

 

• UseCase에서 얻은 Entity를 Presentation 계층에서 사용하는 Model으로 변환
• View에서 사용하기 위해 최적화된 Model 만들기

Repository

 

• UseCase를 통해 필요한 데이터의 CRUD 담당
• Repository는 데이터를 처리하는 로직을 정의하지만 데이터를 처리하는 방법을 모른다.
• Domain 계층으로 설명했지만 실태로는 Domain 계층과 Data 계층의 Input & Output

 

---

Data Layer

• 통신 및 데이터 관리 로직 담당

DataStore

 

• 데이터를 실제로 취득 갱신하는 처리를 기술
• 서버로부터 데이터를 취득할지, DB나 캐쉬의 데이터를 사용하는지 여부도 여기에서 판단
• iOS에서는 API 통신, Realm, CoreData 등을 다루는 구현에 해당

Entity

 

• DataStore로 처리할 수 있는 데이터의 정적 모델
• Entity 자체를 직접 조작하지 않고 Value 객체로 사용
• Entity는 Presentation 계층에서 사용되지 않는다

 

---

SOLID원칙과 Clean Architecture

Clean Architecture오른쪽 하단에 있는 그림에서 어떤식으로 모듈사이의 통신이 이뤄지는지 확인할 수 있다.

인터페이스를 통해 Usecase에 의존하지 않고 Input에 대한 Output의 흐름을 이어나간다.

SOLID원칙의 DIP(의존성 역전 원칙)을 적용한 부분이라고 볼 수 있다. 바깥쪽 원은 아래원을 알 수 없기 때문에

의존성 역전을통한 인터페이스를 호출한다.

위와 똑같은 흐름이 모든 원의 경계에서 일어난다. 동적인 다형성의 이점을 이용해 소스코드의 의존성이 제어흐름의

반대로 동작하도록 한다. 이렇게 하면 제어의 흐름이 어떠한 방향으로 진행되든지 상관없이 의존성 규칙을 지킬 수 있다.

CleanArchitecture의 장점과 단점

장점으로는 소스코드의 유지보수성이 좋아진다.

큰 프로젝트의 경우 클린아키텍처 기반의 폴더링과 모듈분리로 인해 개발자가 필요한 부분을 확인하거나 수정할 때

좀더 수월하게 확인할 수 있는 장점이 있다. 이외에도 테스터블한 구조등등 여러 장점이 있다.

 

하지만, CleanArchitecture를 무조건 적용한다고 좋은 프로그램이 될 수 있는건 아니다.

간단한 로직을 구현할 때 많은 클래스와 모듈을 만들어서 적용해야하는 부담이 존재할 수 있다.

이럴땐 너무 클린아키텍처에 의존하지 말고 요소들을 통합하거나 축약하면서 적당한 프로젝트를 구성하는것도 방법이라고 생각한다.

Architecture에 대한 나의 견해

모바일 앱 개발을 하면서 여러 가지 아키텍처를 알아가고 적용해 보면서 어떤 아키텍처는 사용했지만 큰 장점을 느끼지 못한 부분도 있고

오히려 구조가 복잡해지지는 않는가에 대해 생각한 적이 있다. 이 고민을 하면서 캠퍼들과 얘기 중이었을 때 필요할때 적용하면 된다 라는 말을 들은 적이 있다. 직접 경험해보고 느끼면 가장 좋겠지만 협업에 있어서의 통일성과 유지보수의 용이성 등 다양한 이유에서 필요성을 느낄 때 아키텍처를 사용한다고 생각한다.

 

 

참고 : http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

참고 : https://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc