clean-architecture

22. 클린 아키텍처

이들 아키텍처는 세부적인 면에서는 다소 차이가 있더라도 그 내용은 상당히 비슷하다.

목표는 관심사의 분리이다.

모두 소프트웨어를 계층으로 분리함으로써 관심사의 분리라는 목표를 달성할 수 있었다.

각 아키텍처는 최소한 업무 규칙을 위한 계층 하나와, 사용자와 시스템 인터페이스를 위한 또 다른 계층 하나를 반드시 포함한다.

위 아키텍처들의 특징

프레임워크 독립성
- 아키텍처는 다양한 기능의 라이브러리를 제공하는 소프트웨어, 즉 프레임워크의 존재 여부에 의존하지 않는다.
테스트 용이성
- 업무 규칙은 UI, 데이터베이스, 웹 서버, 또는 여타 외부 요소가 없이도 테스트할 수 있다.
UI 독립성
- 시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다.
데이터베이스 독립성
- 오라클이나 MS SQL 서버를 몽고, 빅테이블, 카우치DB 등으로 교체 가능하다. 업무 규칙은 데이터베이스에 결합되지 않는다.
모든 외부 에이전시에 대한 독립성
- 실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다.

Untitled

클린 아키텍처 그림 같은 경우 보통 안으로 들어갈수록 고수준의 소프트웨어가 된다.

바깥쪽 원은 메커니즘이고, 안쪽 원은 정책이다.

소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다.

내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다.

외부의 원에 선언된 데이터 형식도 내부의 원에서 절대로 사용해서는 안 된다.

엔티티는 전사적인 핵심 업무 규칙을 캡슐화한다.

메서드를 가지는 객체이거나 일련의 데이터 구조와 함수의 집합일 수도 있다.

유스케이스 계층의 소프트웨어는 애플리케이션에 특화된 업무 규칙을 포함한다.

유스케이스 계층의 소프트웨어는 시스템의 모든 유스케이스를 캡슐화하고 구현한다.

인터페이스 어댑터 계층은 일련의 어댑터들로 구성된다. 어댑터는 데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서 데이터베이스나 웹 같은 외부 에이전시에게 가장 편리한 형식으로 변환한다.

마찬가지로 이 계층은 데이터를 엔티티와 유스케이스에게 가장 편리한 형식에서 영속성용으로 사용중인 임의의 프레임워크가 이용하기에 가장 편리한 형식으로 변환한다.

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

위 계층은 모든 세부사항이 위치하는 곳이다. 웹은 세부사항이다.

제어흐름과 의존성의 방향이 명백히 반대여야 하는 경우, 대체로 의존성 역전 원칙을 사용하여 해결한다.

자바 같은 언어에서는 인터페이스와 상속 관계를 적절하게 배치함으로써, 제어흐름이 경계를 가로지르는 바로 그 지점에서 소스 코드 의존성을 제어흐름과는 반대가 되게 만들 수 있다.

유스케이스가 내부 원의 인터페이스를 호출하도록 하고, 외부 원의 프레젠터가 그 인터페이스를 구현하도록 만든다. 동적 다형성을 이용하여 소스 코드 의존성을 제어흐름과는 반대로 만들 수 있고, 이를 통해 제어흐름이 어느 방향으로 흐르더라도 의존성 규칙을 준수할 수 있다.

경계를 가로질러 데이터를 전달할 때, 데이터는 항상 내부의 원에서 사용하기에 가장 편리한 형태를 가져야만 한다.

의존성의 방향에 주목하라. 모든 의존성은 경계선을 안쪽으로 가로지르며, 따라서 의존성 규칙을 준수한다.

이상의 간단한 규칙들을 준수하는 일은 어렵지 않으며, 향후에 겪을 수많은 고통거리를 덜어줄 것이다.

소프트웨어를 계층으로 분리하고, 의존성 규칙을 준수한다면 본질적으로 테스트하기 쉬운 시스템을 만들게 될 것이며, 그에 따른 이점을 누릴 수 있다. 데이터베이스나 웹 프레임워크와 같은 시스템의 외부 요소가 구식이 되더라도, 이들 요소를 야단스럽지 않게 교체할 수 있다.