[Clean Architecture] 22장. 클린 아키텍처

Introduction Link to heading

지난 수십 년간 우리는 시스템 아키텍처와 관련된 여러 가지 아이디어를 봄
- 육각형 아키텍처
  - hexagonal architecture
  - 포트와 어댑터 ports and adapters 라고도 알려져 있음
  - Alistair Cockburn 이 개발
  - Steve Freeman 과 Nat Pryce 가 “테스트 주도 개발로 배우는 객체 지향 설계와 실천”에서 차용
- DCI
  - Data, Context and Interaction
  - James Coplien 과 Trygve Reenskaug 가 만듦
- BCE
  - Boundary-Control-Entity
  - 이바 야콥슨이 “Object Oriented Software Engineering” 에서 소개함
  - 순서를 바꿔 ECB 라고도 많이 씀
이들 아키텍처는 모두 세부적인 면에서는 다소 차이가 있더라도 그 내용은 상당히 비슷
이들의 목표는 모두 같음 → 관심사의 분리 separation of concerns
- 소프트웨어를 계층으로 분리함으로서 관심사의 분리라는 목표를 달성할 수 있었음
이들 아키텍처는 모두 시스템이 다음과 같은 특징을 지니도록 만듦
- 프레임워크 독립성
  - 아키텍처는 프레임워크의 존재 여부에 의존하지 않음
  - 이를 통해 프레임워크를 도구로 사용할 수 있음
  - 프레임워크가 지닌 제약사항안으로 시스템을 욱여 넣도록 강제하지 않음
- 테스트 용이성
  - 업무 규칙은 UI, 데이터베이스, 웹 서버, 또는 외부 요소가 없이도 테스트할 수 있음
- UI 독립성
  - 시스템의 나머지 부분을 변경하지 않고도 UI 를 쉽게 변경할 수 있음
- 데이터베이스 독립성
  - 기존 데이터베이스를 다른 데이터베이스로 교체할 수 있음
  - 업무 규칙은 데이터베이스에 결합되지 않음
- 모든 외부 에이전시에 대한 독립성
  - 실제 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못함

의존성 규칙 Link to heading

클린아키텍처 그림
각각의 동심원은 소프트웨어에서 서로 다른 영역을 표현
보통 안으로 들어갈수록 고수준의 소프트웨어가 됨
바깥쪽 원은 메커니즘이고, 안쪽 원은 정책
이러한 아키텍처가 동작하도록 하는 가장 중요한 규칙은 의존성 규칙 (Dependency Rule)

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

내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못함
- 내부의 원에 속한 코드는 외부의 원에 선언된 어떤 것에 대해서도 그 이름을 언급해서는 안 됨
같은 이유로, 외부의 원에 선언된 데이터 형식도 내부의 원에서 절대로 사용해서는 안 됨
- 특히 그 데이터 형식이 외부의 원에 있는 프레임워크가 생성한 것이라면 더더욱 사용해서는 안됨
우리는 외부의 원에 위치한 어떤 것도 내부의 원에 영향을 주지 않기를 바람

엔티티 Link to heading

전사적인 핵심 업무 규칙을 캡슐화
메서드를 가지는 객체이거나 일련의 데이터 구조화 함수의 집합일 수도 있음
전사적이지 않은 단순한 단일 애플리케이션을 작성하고 있다면 엔티티는 해당 애플리케이션의 업무 객체가 됨
- 이 경우 엔티티는 가장 일반적이며 고수준인 규칙을 캡슐화
외부의 무언가가 변경되더라도 엔티티가 변경될 가능성은 지극히 낮음
운영 관점에서 특정 애플리케이션에 무언가 변경이 필요하더라도 엔티티 계층에는 절대로 영향을 주면 안 됨

유스케이스 Link to heading

유스케이스 계층의 소프트웨어는 애플리케이션에 특화된 업무 규칙을 포함함
유스케이스 계층의 소프트웨어는 시스템의 모든 유스케이스를 캡슐화하고 구현
엔티티로 들어오고 나가는 데이터 흐름을 조정
엔티티가 자신의 핵심 업무 규칙을 사용해서 유스케이스의 목적을 달성하도록 이끔
이 계층에서 발생한 변경이 엔티티에 영향을 줘서는 안 됨
외부요소에서 발생한 변경이 이 계층에 영향을 줘서도 안 됨
유스케이스 계층은 이러한 관심사로부터 격리되어 있음
운영 관점에서 애플리케이션이 변경된다면 유스케이스가 영향을 받으며, 따라서 이 계층의 소프트웨어에도 영향을 줄 것
유스케이스의 세부사항이 변하면 이 계층의 코드 일부는 분명 영향을 받을 것

인터페이스 어댑터 Link to heading

인터페이스 어댑터 Interface Adapter 계층은 일련의 어댑터들로 구성됨
어댑터는 데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서 데이터베이스나 웹 같은 외부 에이전시에게 가장 편리한 형식으로 변환
이 계층은 데이터를 엔티티와 유스케이스에게 가장 편리한 형식에서 영속성용으로 사용 중인 임의의 프레임워크(즉, 데이터베이스)가 이용하기에 가장 편리한 형식으로 변환함
이 원 안에 속한 어떤 코드도 데이터베이스에 대해 조금도 알아서는 안 됨
SQL 기반의 데이터베이스를 사용한다면 모든 SQL 은 이 계층을 벗어나서는 안 됨
특히 이 계층에서도 데이터베이스를 담당하는 부분으로 제한되어야 함
또한 이 계층에는 데이터를 외부 서비스와 같은 외부적인 형식에서 유스케이스나 엔티티에서 사용되는 내부적인 형식으로 변환하는 또 다른 어댑터가 필요함

프레임워크와 드라이버 Link to heading

일반적으로 이 계층에서는 안쪽 원과 통신하기 위한 접합 코드 외에는 특별히 더 작성해야 할 코드가 그다지 많지 않음
프레임워크나 드라이버 계층은 모든 세부사항이 위치하는 곳
웹, 데이터베이스는 모두 세부사항이고 이러한 것들을 모두 외부에 위치시켜서 피해를 최소화함

원은 네 개여야만 하나? Link to heading

하나의 예시일 뿐 더 많은 원이 필요할 수도 있음
항상 네 개만 사용해야 한다는 규칙은 없음
단, 어떤 경우에도 의존성 규칙은 적용됨
소스 코드 의존성은 항상 안쪽으로 향함
- 안쪽으로 이동할수록 추상화와 정책의 수준은 높아짐
- 가장 바깥쪽 원은 저수준의 구체적인 세부사항으로 구성됨
안쪽으로 이동할수록 소프트웨어는 점점 추상화되고 더 높은 수준의 정책들을 캡슐화함
따라서 가장 안쪽 원은 가장 범용적이며 높은 수준을 가짐

경계 횡단하기 Link to heading

그림 22.1 우측하단
제어흐름과 의존성 방향이 명백히 반대여야 하는 경우, 의존성 역전 원칙을 사용하여 해결
- 별다른 조치 없이 제어흐름을 따라 구현하면 안쪽 원의 코드가 바깥쪽 원의 코드를 호출하게 됨
- 하지만 바로 이 지점에서 소스 코드 의존성을 역전시키면, 제어흐름과는 반대로 바깥쪽 원의 코드가 안쪽 원의 코드를 호출하게 만든다는 뜻
예를 들어 유스케이스에서 프레젠터를 호출해야 한다고 가정
- 직접 호출하면 의존성 규칙을 위배하게 됨
- 따라서 우리는 유스케이스가 내부 원의 인터페이스를 호출하도록 하고, 외부 원의 프레젠터가 그 인터페이스를 구현하도록 만듦
아키텍처 경계를 횡단할 때 언제라도 동일한 기법을 사용할 수 있음
- 우리는 동적 다형성을 이용하여 소스 코드 의존성을 제어흐름과는 반대로 만들 수 있고,
- 이를 통해 제어흐름이 어느 방향으로 흐르더라도 의존성 규칙을 준수할 수 있음

경계를 횡단하는 데이터는 어떤 모습인가 Link to heading

경계를 가로지르는 데이터는 흔히 간단한 데이터 구조로 이루어짐
중요한 점은 격리되어 있는 간단한 데이터 구조가 경계를 가로질러 전달된다는 사실
우리는 데이터 구조가 어떤 의존성을 가져 의존성 규칙을 위배하게 되는 일은 바라지 않음
경계를 가로질러 데이터를 전달할 때, 데이터는 항상 내부의 원에서 사용하기에 가장 편리한 형태를 가져야만 함

전형적인 시나리오 Link to heading

데이터베이스를 사용하는 웹 기반 자바 시스템의 전형적인 시나리오
의존성 방향에 주목
- 모든 의존성은 경계선을 안쪽으로 가로지르며, 따라서 의존성 규칙을 준수함

결론 Link to heading

이상의 간단한 규칙을 준사하는 일은 어렵지 않음
향후에 겪을 수많은 고통거리를 덜어줄 것
소프트웨어를 계층으로 분리하고 의존성 규칙을 준수하면, 본질적으로 테스트하기 쉬운 시스템을 만들게 될 것이며, 그에 따른 이점을 누릴 수 있음