클린 아키텍처란?
- 각각의 동심원은 소프트웨어에서 서로 다른 영역을 표현한다.
- 보통 안으로 들어갈수록 고수준의 소프트웨어가 된다. 바깥쪽 원은 메커니즘이고 안쪽 원은 정책이다.
- 이런 아키텍처가 동작하도록 하는 가중 중요한 규칙은 의존성 규칙이다.
- 내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다. 같은 이유로 외부의 원에 선언된 데이터 형식도 내부의 원에서 절대로 사용해서는 안 된다.
참고 - 주니어 개발자의 클린 아키텍처 맛보기
엔티티(Entity)
- 엔티티는 전사적인 핵심 업무 규칙을 캡슐화한다. 엔티티는 메서드를 가지는 객체이거나 일련의 데이터 구조와 함수의 집합일 수도 있다.
- 전사적이지 않은 단순한 단일 애플리케이션을 작성하고 있다면 엔티티는 해당 애플리케이션의 업무 객체가 된다.
- 이 경우 엔티티는 가장 일반적이며 고수준인 규칙을 캡슐화한다. 외부의 무언가가 변경되더라도 엔티티가 변경될 가능성은 지극히 낮다.
- 운영 관점에서 특정 애플리케이션에 무언가 변경이 필요하더라도 엔티티 계층에는 절대로 영향을 주어서는 안 된다.
유스케이스(UseCase)
- 유스케이스 계층의 소프트웨어는 애플리케이션에 특화된 업무 규칙을 포함한다.
- 또한 유스케이스 계층의 소프트웨어는 시스템의 모든 유스케이스를 캡슐화하고 구현한다. 유스케이스는 엔티티로 들어오고 나가는 데이터 흐름을 조정하며, 엔티티가 자신의 핵심 업무 규칙을 사용해서 유스케이스의 목적을 달성하도록 이끈다.
- 이 계층에서 발생한 변경이 엔티티에 영향을 줘서는 안 된다. 또한 데이터베이스, UI, 또는 여타 공통 프레임워크와 같은 외부 요소에서 발생한 변경이 이 계층에 영향을 주어선 안 된다. 유스케이스 계층은 이런 관심사로부터 격리되어 있다.
- 하지만 운영 관점에서 애플리케이션이 변경된다면 유스케이스가 영향을 받으며, 이 계층의 소프트웨어에도 영향을 줄 것이다. 유스케이스의 세부 사항이 변하면 이 게층의 코드 일부는 분명 영향을 받을 것이다.
인터페이스 어댑터(Interface Adapter)
- 인터페이스 어댑터 계층은 일련의 어댑터들로 구성된다. 어댑터는 데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서 데이터베이스나 웹 같은 외부 에이전시에게 가장 편리한 형식으로 변환된다.
- 이 계층은 데이터를 엔티티와 유스케이스에게 가장 편리한 형식에서 영속성용으로 사용 중인 임의의 프레임워크(즉, 데이터베이스)가 이용하기에 가장 편리한 방식으로 변환한다.
- 예컨대 SQL 기반의 데이터베이스를 사용한다면 모든 SQL은 이 계층을 벗어나서는 안 된다. 특히 이 계층에서도 데이터베이스를 담당하는 부분으로 제한되어야 한다.
프레임워크와 드라이버(Framework & Driver)
- 프레임워크와 드라이버 계층은 모든 세부사항이 위치하는 곳이다. 웹은 세부사항이다. 데이터베이스 역시 세부사항이다.
- 우리는 이러한 것들을 모두 외부에 위치시켜서 피해를 최소화한다.
원은 꼭 4개여야만 하는가?
- 결론부터 말하자면 꼭 4개일 필요가 없다.
- 전달하고자하는 부분은 바로 의존성 규칙은 언제 어디서든 적용된다는 것이다. 안쪽으로 이동할수록 추상화와 정책의 수준은 높아진다. 가장 바깥쪽 원은 저수준의 구체적인 세부사항으로 구성된다.
경계를 횡단하는 데이터는 어떤 모습인가?
- 경계를 가로지르는 데이터는 흔히 간단한 데이터 구조로 이루어져 있다.
- 기본적인 구조체나 간단한 데이터 전송 객체(DTO, Data Transfer Object) 등 원하는 대로 고를 수 있다.
- 예를 들어 많은 데이터베이스 프레임워크는 쿼리에 대한 응답으로 사용하기 편리한 데이터 포맷을 사용한다. 이런 포맷은 행(row) 구조가 많다.
- 이런 행 구조가 경계를 넘어 내부로 그대로 전달되는 것을 원치 않는다. 이렇게 되면 의존성 규칙을 위배하게 되기 때문이다. 따라서 경계를 가로질러 데이터를 전달할 때, 데이터는 항상 내부의 원에서 사용하기에 가장 편리한 형태를 가져야만 한다.