clean architecture

clean architecture

clean architecture 는 어떤 system architecture 가 좋은 architecture 인지 논의하는 과정에서 로버트 C. 마틴(Robert C. Martin) 가 집약시킨 개념이다. 동명의 저서도 존재한다.

 

잠깐 로버트 C. Martin 에 대해 적자면, clean code 의 저자이자 오브젝트 멘터사의 대표로 객체 지향 설계, 애자일 방법론(agile methodology)과 익스트림 프로그래밍(eXtreme programming) 컨설팅 등 여러 분야에서 활동하고 있는 저명하고 전설적인 프로그래머라고 한다.

 

바로 이 책이 clean architecture 이다.

blue print

clean architecture 는 아래의 다이어그램과 같은 구조를 지향한다.

 

각각의 동심원은 소프트웨어의 각기 다른 영역을 나타내고 있다. 바깥쪽으로 갈수록 고수준의 소프트웨어로, 소스코드는 화살표의 방향 대로 안쪽을 향해서만 의존할 수 있다. 안쪽의 원에서는 바깥쪽의 원에 대해 전혀 알지 못하며, 바깥쪽의 원에서 선언되거나 생성된 객체를 안쪽 원에서는 참조할 수 없다. 하지만 반대로 바깥쪽에서는 안쪽에 대하여 알 수 있다. 안쪽에서 선언되거나 생성된 객체를 가져와서 사용할수도 있다. 이를 clean architecture의 의존성 규칙(dependency rule) 이라고 한다.

entity

가장 안쪽에 있는 entity 라는 개념에 대해서 이전의 포스팅에서 논한 바있다. entity 는 핵심 비즈니스 규칙을 캡슐화한다.
entity 의 개념에 대해서는 아래의 그림이 가장 이해하기 쉬운거 같아 한번 더 참조한다.

 

entity 는 가장 안쪽에 존재하는 만큼 database 와 직접적으로 소통한다. entity 에서는 db 와 주고받는 데이터를 모델로 정의한다. 바깥쪽에서 무엇이 변경되더라도 entity 에는 아무 영향도 끼칠 수 없다.

usecase

use case 단에서는 애플리케이션 고유의 비즈니스 로직을 실행하는 layer 이다. entity 의 흐름과 동작을 조합하여 캡슐화하고 구현화한다. 이 부분에 대해 이해가 잘 가지 않는데, class 와 비슷한 개념이 아닐까 생각한다.

controllers / gateways / presenters

해당 부분은 interface adapter 라고도 한다. 이 계층에서 데이터는 entity 나 usecase 에 용이한 형태에서 DTO 등의 형태를 통해 사용하고 있는 프레임워크에 용이한 형으로 변환된다.

 

ref) craftsmanshipcount - Clean Architecture: A Comparison to and Critique of Java Best Practice

framework & drivers

가장 바깥쪽의 원은 database 나 웹 프레임워크 등의 도구들로 구성된다.
이 곳에서 data 는 로컬 또는 리모트에서 데이터를 어떻게 가져올지에 대해서 구현한다. 프레임워크에 대한 의존성을 가지고, 데이터모델에 의해 가져온 데이터를 entity 에 맞게 바꿔주는 매핑 작업을 하여 usecase로 반환한다고 설명하면 이해하기가 쉽다.

무엇이 좋은 구조일까?

clean architecture 는 system architecture 의 정답이 아니라, '무엇이 좋은 구조일까?' 라는 질문에 대한 여러 대답과 논의 중 하나이다. 타임러시가 존재하는 상황에서 clean architecture 는 비합리적인 선택일 수 있으며, 사용하려는 프레임워크와 언어에 대해 깊은 이해가 없다면 실제로 적용할때에 어떤 기준으로 경계를 나누어야 하는지 명확하지 않아 이전보다 더 가독성이 떨어지는 코드가 만들어질수도 있다.

 

그렇다면 무엇이 좋은 구조일까? 좋은 구조에 대해 공통적으로 다루어지는 쟁점들은 아래와 같다.

 

좋은 구조란, 비즈니스 변경사항에 최대한 빠르게 대응하면서 시스템 경쟁력을 높일 수 있는 능력을 갖추고 있어야 한다. 시스템은 확장 가능해야 하고, 유지하기 쉬워야 한다. 적절한 경계를 기준으로 잘 나누어져 모든 모듈 및 매커니즘의 교체가 시스템을 중단하는 일 이루어질 수 있어야 한다. 프레임워크의 라이브러리에 의존하지 않도록, 프레임워크에 대해 독립적이어야 한다. 테스트가 용이해야 하고, 가능한 정보를 최대한 많이 가지고 있으면서도 중요한 결정을 미루는게 가능하도록 강력한 기초를 가져야 한다.

 

그러므로 무조건적으로 clean architecture 를 따라 코드를 구조화하기 보다는, 이러한 개념이 있으며 이러한 방법을 통해 적용하여 보다 더 좋은 코드를 만들기 위해 노력하겠다는 관점으로 이용하면 좋을거 같다.