클린 아키텍처에 대해 아라보자

새로 개발을 시작하면서, 클린 아키텍처에 대해 공부하고 정리하려한다.
시작해보자.

시중(?)에 있는 다양한 아키텍처들의 특징

1. 프레임워크 독립적
   클린 아키텍처는 소프트웨어 라이브러리 존재 여부에 의존하지 않는다.
2. 테스트 용이
   비즈니스 규칙은 UI, 데이터베이스, 웹 서버, 기타 외부 요인없이 테스트가 가능하다.
3. UI 독립적
   시스템의 나머지 부분을 변경할 필요 없이 UI를 쉽게 변경할 수 있다.
4. 데이터베이스 독립적
   오라클 또는 SQL Server를 몽고, 빅테이블 카우치 DB 등으로 바꿀 수 있다. 비즈니스 규칙은 데이터베이스에 얽매이지 않는다.
5. 외부 기능 독립적
   비즈니스 규칙은 외부 세계에 대해 아무것도 모른다.

다양한 아키텍처를 하나의 아이디어로 통합하며, 소개한 것이 클린 아키텍처 by. 로버트 C. 마틴 (Uncle Bob)

의존 규칙

위 그림은 소프트웨어의 각각 다른 영역을 나타내고 있는데, 바깥쪽의 레이어를 메커니즘(Mechanism)이라 하고, 안쪽의 레이어는 정책(Policy)이다.

클린 아키텍처를 기능하게 하는 가장 중요한 규칙이 의존 규칙인데, 이 규칙에 의해 소스 코드는 안쪽 레이어를 향해서만 의존할 수 있다. 즉, 안쪽의 레이어는 바깥쪽에 레이어에 대해 전혀 모른다. 따라서 바깥쪽의 레이어에서 선언된 어떠한 이름도 참조할 수 없다. 이는 함수, 클래스, 변수 등 이름이 붙은 소프트웨어의 엔티티 모든 것에서 해당된다.

엔티티

엔티티는 비즈니스 규칙을 캡슐화 한다. 엔티티는 메서드를 갖는 객체일 수도 있지만 데이터 구조와 함수의 집합일 수도 있다. 엔티티는 가장 일반적이면서 고수준의 규칙을 캡슐화 하며, 바깥 레이어에서 무엇이 변경되더라도 바뀌지 않는다.

유스케이스

유스케이스는 시스템의 동작을 사용자의 입장에서 표현한 시나리오다. 해당 레이어의 소프트웨어는 시스템의 모든 유스케이스를 캡슐화하고 구현한다. 유스케이스는 엔티티와의 데이터 흐름을 조정하고, 엔티티가 유스케이스의 목표를 달성하도록 지시한다.

유스케이스의 변경이 엔티티에 영향을 주어서는 안되며, 데이터베이스, UI, 프레임워크의 변경으로부터 유스케이스가 영향을 받지 않는다. 하지만, 애플리케이션의 조작에 대한 변경이 일어나면 유스케이스에 영향을 미칠 수 있다.

인터페이스 어댑터

인터페이스 어댑터는 유스케이스와 엔티티로부터, 데이터베이스나 웹 등 외부 기능에 용이한 형식으로 데이터를 변환한다. 즉, 바깥 또는 안쪽으로 전달되는 모든 데이터를 데이터를 전달 받는 레이어에 맞게 변환시켜주는 역할을 한다. 예를 들면 View 레이어로 전달되는 데이터를 문자열로 변경해 전달하는 것이 있다. 프리젠터, 뷰, 컨트롤러는 모두 해당 레이어에 속한다.

프레임워크와 드라이버

가장 바깥쪽의 레이어는 일반적으로 프레임워크나 도구로 구성된다. 해당 레이어에 포함되는 것들은 다음과 같다.

• 네트워크(HTTP, API, 소켓 등)
• UI(Web UI, ViewController, Activity 등)
• 데이터베이스(SQL, NoSQL, In-Memory 등)
• 라이브러리와 프레임워크
• I/O 장치(터치 스크린, 키보드, 스피커 등)

이 레이어에 있는 것들은 매우 빈번하게 변경되는 것이므로 추상화와 제어의 역전을 통해 변경으로부터 안전하게 만들어야 한다.

교차경계

The clean architecture 다이어그램의 오른쪽 아래를 보면 위와 같은 그림을 볼 수 있다. 이는 인터페이스 어댑터 레이어에 속하는 컨트롤러와 프리젠터가 안쪽 레이어인 유스케이스와 통신하는 방식을 보여준다.
해당 그림에서는 흐름이 컨트롤러에서 시작해서 유스케이스를 거쳐 프리젠터로 간다. 그런데 이제까지 계속 안쪽 레이어는 바깥쪽 레이어를 알 수 없다고 했는데, 유스케이스가 프리젠터로 어떻게 가는 것 일까?

유스케이스가 프리젠터를 호출할 필요가 있을 때, 호출은 직접 이뤄질 수 없다. 의존성 규칙을 위반하기 때문이다. 따라서 유스케이스에는 안쪽 레이어에 있는 인터페이스(여기서는 Use Case Output Port)를 호출한다. 그리고 유스케이스 레이어 바깥쪽의 프리젠터는 이 인터페이스를 구현한다.

이런 방식으로 아키텍처의 경계가 만나는 곳에서 통신이 이루어진다. SOLID 원칙 중 하나인 의존 관계 역전의 원칙(Dependency Inversion Principle)을 통해 문제점을 해결하여, 소스코드의 의존성이 제어 흐름의 반대가 되도록 한다.

참고

https://blog.coderifleman.com/2017/12/18/the-clean-architecture/

https://justwrite99.medium.com/clean-architecture-part-2-the-clean-architecture-3e2666cdce83

https://zeddios.tistory.com/1065