Clean Architecture

의존성 규칙 

 

클린 아키텍처

 대부분의 아키텍처는 세부적인 면은 차이가 있어도 관심사의 분리라는 공통된 목표를 가지고 있다. 이를 소프트웨어의 계층을 분리함으로 달성할 수 있다. 위의 그림은 해당 아이디어를 구현한 다이어 그램인데, 분리된 계층에서 안쪽으로 들어갈 수록 고수준의 소프트웨어가 된다.  

 

고수준, 저수준에 대해 내가 이해한 바로는 다음과 같다.

- 고수준 : 정책, 추상회된 개념, 외부에 의해 변화가 생기지 않는 프로그램 
내가 사용했던 코드들을 예로 생각해보면 
RealmManager : 데이터를 Realm DB에 CRUD한다. 
AlamofireManager: 네트워크 통신을 호출한다. 

- 저수준 : 구체적인 동작, 세부적인 동작을 결정해주는 프로그램 
DrawingManager : Drawing 데이터를 Realm 에 DB에 CRUD 한다.
AlamofireManager : OO URL로 해당 데이터를 호출한다.  

 

 

이러한 아키텍처가 동작하도록 하는 가장 중요한 규칙은 의존성 규칙이다. 정의는 다음과 같다. 소스코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다. 내부의 원이 외부의 원에 대해 의존하는 것이 하나도 없어야 한다.  

 

각각 원에 해당하는 내용들은 다음과 같다 .

 

엔티티 

엔티티는 총괄적인 핵심 업무 칙을 캡슐화 한다. 이는 메서드를 가지는 개체이거나 일련의 데이터 구조와 함수의 집합일 수 있다. 다양한 코드에서 재사용 할 수만 있다면 형태는 그다지 중요하지 않다.  

또한 엔티티는 변경될 가능성이 매우 낮으며 애플리케이션에 변화가 필요하더라도 엔티티 계층에 영향을 주어서는 절대 안된다. 

 

 

유스케이스

애플리케이션에 특화된 업무 규칙을 포함한다. 엔티티로 들어오고 나가는 데이터 흐름을 조정하며, 엔티티의 핵심 업무 규칙을 사용해 유스케이스의 목적을 달성하도록 이끈다. 

 

 

 

인터페이스 어댑터 

데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서, 외부 에이전시에게 가장 편리한 형식으로 변홚나다. 프레젠터, 뷰, 컨트롤러는 모두 인터페이스 어댑터 계층에 속한다. 
내가 이해하기로 MVC 패턴의 컨트롤러가 대표적인 인터페이스 어댑터인 것 같다. 예를 들자면 컨트롤러가 모델을 유스케이스로 전달해 어떻게 처리할지 알려주고, 이를 다시 VIew에 전달하는 개념인 것 같다.

 

 

 

프레임워크와 드라이버 

일반적으로 세부사항들이 위치한 곳이다. 데이터베이스나 웹 프레임워크 같은 프레임워크나 도구로 구성된다. 일반적으로 이 계층에서 안쪽 원과 통신하기 위한 접합 코드 외에는 특별히 더 작성해야 할 코드가 많지 않다. 

 

 

 

 

경계 횡단하기

그림의 우측 하단을 보면 경계를 횡단하는 예가 있다. 이 제어 흐름은 컨트롤러에서 유스케이스를 지난후 프레젠터에서 마무리된다. (분홍색 화살표)  소스코드 또한 각 의존성은 유스케이스를 향해 안쪽을 가리킨다. 그런데 제어흐름과 의존성의 방향이 반대여야 하는 경우, 대체로 의존성 역전 원칙을 사용하여 해결한다. 예를 들어 유스케이스에서 프레젠터를 호출할 때에 직접 호출하면 안된다. 따라서 유스케이스가 내부의 인터페이스를 호출하게 하고, 외부원의 프레젠터가 그 인터페이스를 구현하게 만든다. Swift에서는 Protocol로 구현할 수 있을 것 같은데 아직 감이 안온다. 다른 예제 코드들을 살펴보면서 프로젝트에 적용해봐야될 것 같다.