Clean Architecture 5부: 아키텍처

jiffydev·2021년 5월 5일

clean architecture

Clean Architecture

목록 보기

4/5

로버트 C. 마틴의 클린 아키텍처를 읽고 내용 요약 및 생각 정리용 포스트

요약

정책과 세부사항을 엄격하게 분리함으로써 세부사항은 최대한 늦게 결정할 수 있고, 이를 통해 시스템이 세부사항에 의존하지 않기 때문에 개발, 배포, 유지보수가 상대적으로 간단해진다.
시스템의 독립성을 위해 유스케이스의 계층 또는 유스케이스 자체를 기준으로 결합 분리해야 한다. 유스케이스의 계층은 유스케이스 안에서의 업무 규칙이나 세부사항을 의미하고, 이러한 것들이 서로 다른 이유로 변경된다면 분리하고 같은 이유로 변경되면 결합해야 한다.
유스케이스 자체의 결합 분리는 유스케이스의 역할에 따라 나누는 것으로 하나의 유스케이스는 수평적 계층 각각이 가진 기능의 일부를 사용하게 된다.

이처럼 시스템을 수평적으로 분할하면서 동시에 수직적으로 가로지르는 유스케이스로 시스템을 다시 나눌 수 있고, 이로 인해 기존 요소에 지장을 주지 않고도 새로운 유스케이스를 추가할 수 있다.
결합 분리 모드는 소스 수준, 배포 수준, 서비스 수준으로 분리할 수 있는데, 어느 수준을 선택하는가는 프로젝트의 진행 상황에 따라 변할 수 있지만 좋은 아키텍처는 이를 선택 사항으로 남겨, 언제든 되돌릴 수 있어야 한다.
아키텍처는 소프트웨어 요소간의 경계(선 긋기)를 세워 분리함으로써, 핵심 업무 로직이 오염되지 않도록 하고 부수적 결정(프레임워크, 데이터베이스 등)을 최대한 미룰 수 있도록 하는 것.
결국 선을 긋는 것은 핵심적인 업무 규칙 컴포넌트와 그 외의 컴포넌트를 분리하고, 그 외의 컴포넌트들은 플러그인 형태로 만들어 업무 규칙에 절대 영향을 미치지 못하도록 하는 것이다. 이를 통해 플러그인을 쉽게 변경할 수 있고, 이러한 변경이 업무 규칙에는 영향을 주지 않게 된다.
컴포넌트를 연결할 때는 의존성의 방향을 저수준 컴포넌트-> 고수준 컴포넌트로 설정해야 한다. 그래야 저수준에서 변경이 발생하더라도 고수준에 영향을 미치지 않는다.
업무 규칙은 핵심 규칙/데이터가 들어 있는 엔티티와 애플리케이션에 특화된 업무 규칙인 유스케이스를 포함한다. 이러한 업무 규칙은 아키텍처의 가장 안쪽에 위치하여, 저수준에 영향을 받아서는 안된다.
아키텍처는 애플리케이션의 유스케이스에 대해 소리쳐야 한다.(웹, 프레임워크를 주장하는 것이 아닌)
클린 아키텍처에서 가장 중요한 규칙은 의존성 규칙으로, 소스코드 의존성은 반드시 고수준의 정책을 향해 의존해야 한다.
험블 객체 패턴을 통해 테스트하기 어려운 객체를 따로 모으면 테스트 하기 쉬운 객체만 테스트하면 되므로, 시스템이 전체적으로 테스트하기가 쉬워 진다.
완벽한 경계를 만드는 데는 시간과 비용이 많이 소요되므로, 일시적으로 부분적 경계를 구현해서 경계를 만들 수도 있다. 부분적 경계를 구현하는 방법으로는, 마지막 단계(실질적 컴포넌트 분리)를 건너뛰기, (의존성 역전은 구현하되 쌍방향 boundary 인터페이스가 없는)일차원 경계, 경계를 퍼사드(Facade) 클래스로만 간단히 구현하는 방식 등이 있다.
아키텍처의 경계는 어디에나 존재하고, 이를 제대로 구현하려면 비용이 많이 든다. 따라서 아키텍트는 반드시 필요한 경계와 아직은 무시해도 좋은 경계를 구분할 수 있는 능력이 있어야 하고, 경계를 구현할 때의 손익을 판단할 수 있어야 한다.
메인 컴포넌트는 가장 저수준의 컴포넌트로, 고수준의 시스템을 위한 모든 것들을 로드하여 제어권을 고수준의 시스템에게 넘기는 일만 맡게 된다. 따라서 메인 컴포넌트는 애플리케이션의 플러그인이라 할 수 있기 때문에 애플리케이션의 설정에 따라 메인을 나누어 설정 관련 문제를 쉽게 풀 수 있다.
아키텍처의 경계는 서비스를 관통하기 때문에 이러한 횡단 관심사를 해결하기 위해서는 서비스 내부를 의존성 규칙도 준수하는 컴포넌트 아키텍처로 설계해야 한다.