[Clean Architecture] 소리치는 아키텍처, 클린 아키텍쳐 소개

소리치는 아키텍처

도서관의 아키텍처를 보고 있다고 생각해 봅시다. 커다란 창문, 체크인과 체크아웃을 담당할 사서를 위한 공간, 독서 공간, 작은 회의실, 도서관의 장서를 모두 보관할 정도의 책상을 배치한 진열실이 차례대로 나타납니다. 이 아키텍쳐는 도서관!이라고 소리칠 것입니다.

자, 이제 각각의 프로젝트를 들여다 봅시다. 그 프로젝트는 뭐라고 소리칠까요? 헬스케어 시스텀, 재고관리 시스템 또는 Spring, ASP 라고 소리치고 있을수도 있습니다. 전자는 아주 좋은예이고 후자는 나쁜예입니다. 이 아키첵쳐를 봤을 때, 어떤 프레임워크가 떠오르는것이 아니라, 이게 무슨 프로그램이 떠오르는것이 좋습니다.

즉, 아키텍처는 프레임워크에 대한것이 아닙니다. 아키텍처는 유즈케이스 중심이라고 할 수 있습니다.

아키텍처는 시스템을 이야기해야 하며, 시스템에 적용한 프레임워크에 대해 이야기해서는 안됩니다. 헬스케어 시스템을 구축하고 있다면, 새로 들어온 프로그래머가 소스 저장소를 봤을 때 첫인상은 “오, 헬스케어 시스템이군”이어야 합니다. 또한, 계속 강조되는 말인 “세부사항은 최대한 나중에 결정하기”라는 원칙을 지켜야 합니다.

클린 아키텍처

앞서 말했던, 여러가지 이야기들을 (관심사 분리, 프레임워크 독립성, 테스트 용이성, UI 독립성, 데이터베이스 독립성, 외부 에이전시에 대한 독립성) 모두 합쳐 클린 아키텍쳐모델을 만들었습니다.

• 프레임워크 독립성, 아키텍처는 다양한 기능의 라이브러리를 제공하는 소프트웨어, 즉 프레임워크의 존재 여부에 의존하지 않는다. 이를 통해 이러한 프레임워크를 도구로 사용할 수 있으며, 프레임워크가 지닌 제약사항안으로 시스템을 욱여 넣도록 강제하지 않는다.
• 테스트 용이성, 업무 규칙은 UI, DB, 웹서버, 또는 여타 외부 요소가 없이도 테스트할 수 있다.
• UI 독립성, 시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다. 예를들어 업무 규칙을 변경하지 않은 채 웹 UI를 콘솔 UI로 대체할 수 있다.
• 데이터베이스 독립성, 오라클이나 MSSQL서버를 몽고DB 또는 카우치DB등으로 교체할 수 있다.
• 모든 외부 에이전시에 대한 독립성, 실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다.

위의 사진이 Clean Architecture의 구조도 입니다. 원 안의 화살표는 의존성의 방향이고, 원 밖에 있을수록 저수준의 모듈, 원 안에 있을수록 고수준의 모듈입니다. 또한, 내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못합니다. 특히 내부의 원에 속한 코드는 외부의 원에 선언된 어떤 것에 대해서도 그 이름을 언급해서는 안됩니다.(여기에는 함수, 클래스, 변수, 그리고 소프트웨어 엔티티로 명명되는 모든것이 포함됩니다.)

엔티티 (Entities)

도메인 계층으로도 불리며, 엔티티 계층은 하나 이상의 프로그램 간에 공유될 수 있다는 가정하에 만드는 수명이 긴 객체입니다. (즉, 재사용의 가능성이 높다는 것을 인지하고 외부에 의해 변경될 가능성을 낮추어야 합니다.)

이곳에는 데이터를 포함하거나 핵심이 되는 비즈니스 규칙을 캡슐화하게 됩니다. 또한, 다른 모듈에 의해 오염이 되어서는 절대 안됩니다.

유즈케이스 (Use cases)

애플리케이션 계층으로도 불리며, 어플리케이션 규모의 비즈니스 규칙을 포함합니다. 인프라 단의 DB나 UI, 라이브러리와 같은 외부요소에 의해 영향을 받지 않는다는 것을 원칙으로 합니다. 금융권을 예로들면, 신용도가 1000이상 되는 사람에게 대출을 승인해준다 라는 규칙이 유즈케이스에 해당됩니다.

인터페이스 어뎁터 (Interface Adapter)

어뎁터 계층은 DB나 Web, UI와 같은 바깥 계층에서 사용하기 편리하도록, 유즈케이스 또는 엔티티 계층에서 데이터를 변환하는 어뎁터의 집합입니다.

흔히 MVC, MVVM과 같은 아키텍처를 포함하는 것이 이 영역으로 컨트롤러, 프레젠터, 게이트웨이 등이 속합니다.

프레임워크와 드라이버 (Frameworks & Drivers)

인프라 계층이라고도 불리며, 가장 외부에 있는 레이어로 DB, 웹 프레임워크와 같은 세부 정보(Details)를 나타내는 계층입니다.

이곳은 보통 글루 코드(Glue code)만 작성하며, 시간이 지남에 따라 구성이 변경될 수 있으므로 엔티티 계층(또는 도메인 계층)에 추상화(abstracted)하여 도메인 계층에 영향을 주지 않고 인터페이스를 수정하고 업데이트할 수 있습니다.

원은 꼭 네개인가?

아닙니다. 새로운 계층이 필요하다면 더 늘리면 됩니다. 하지만 주의해야할 점은, 의존성 규칙 (저수준 모듈이 고수준의 모듈에 의존해야 함)은 반드시 지켜줘야 합니다.

경계 횡단하기

고수준의 모듈은 저수준의 모듈과 자유롭게 통신할 수 있습니다. 하지만, 저수준의 모듈도 고수준의 특정 모듈을 참조해야할 때가 있습니다. 이때 저수준의 모듈에서 인터페이스를 정의하고, 고수준의 모듈에서 행동을 정의하는 방식으로 해결합니다. 이것은 delegate 문법을 언어차원에서 지원하지 않는 언어의 경우이고, 결국 delegate객체를 통해 소통해야 한다는 뜻입니다.

결론

이런 규칙들을 준수하는 일은 어렵지 않으며, 향후에 겪을 수많은 고통거리를 덜어줄 것입니다. 소프트웨어를 계층으로 분리하고 의존성 규칙을 준수한다면 데이터베이스나 웹 프레임워크와 같은 시스템의 외부 요소가 구식이 되더라도, 이들 요소르를 야단스럽지 않게 교체할 수 있습니다.

Clean Architecture 카테고리 내 다른 글 보러가기