[Architecture] Clean Architecture

안녕하세요 제인입니다 :)

유연한 설계에 관심이 많아지면서 클린 아키텍처에 대해 쫌쫌따리로 공부는 하고 있었지만, 머릿속에 확실하게 개념이 잡혀있진 않은 상태였는데.. 이제는 프로젝트에 적용까지 해보고 싶어서 클린 아키텍처에 대해 정리를 해보려고 합니다!

이번 게시글에서는 Robert C. Martin의 The Clean Architecture 라는 글을 번역해보면서 클린 아키텍처 개념에 대한 정리를 해보겠습니다.

Clean Architecture란?

클린 아키텍처는 Robert C. Martin(aka 엉클밥, 밥아저씨)에 의해 고안된 소프트웨어 아키텍처 패턴입니다.

밥아저씨가 클린 아키텍처를 대체 왜 만들게 되었냐.. 하면! 기존의 여러 아키텍처에서 유사성을 찾았기 때문입니다.

기존의 아키텍처들은 세부적인 사항은 다르지만 모두 관심사의 분리(separation of concerns)라는 동일한 목표를 가지고 있었습니다.

 

이들은 모두 소프트웨어를 계층(layer)로 나누어 분리를 달성하고 있었는데, 각 아키텍처는 비즈니스 로직을 위한 계층과 인터페이스를 위한 계층을 적어도 하나씩 가지고 있었습니다.

 

이러한 아키텍처들은 다음의 특징을 가진 시스템을 생성합니다.

 

1. Independent of Frameworks. 프레임워크에 독립적

아키텍처는 기능이 포함된 소프트웨어 라이브러리의 존재 여부에 의존하지 않고, 프레임워크를 도구로 사용할 수 있습니다.

 

2. Testable. 테스트 가능

비스니스 로직은 UI, 데이터베이스, 웹 서버 또는 기타 외부 요소 없이 테스트할 수 있습니다.

 

3. Independent of UI. 독립적인 UI

시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있습니다.

ex. 비즈니스 로직을 변경하지 않고도 웹 UI를 콘솔 UI로 교체 가능

 

4. Independent of Database. 독립적인 데이터베이스

비즈니스 로직이 데이터베이스에 바인딩되지 않습니다. 

 

5. Independent of any external agency. - 외부 세계로부터 독립적

비즈니스 로직은 외부 세계에 대해 전혀 알지 못합니다.

 

이러한 아키텍처들을 단일 개념으로 통합하고자 고안된 아키텍처가 바로 Clean Architecture입니다.

The Dependency Rule

마틴은 소프트웨어를 총 4개의 레이어로 나눴습니다.

이 아키텍처를 작동시키는 가장 우선적인 규칙은 종속성 규칙(Dependency Rule)입니다.

종속성 규칙은 다음과 같습니다.

1. 소스코드 종속성은 안쪽으로만 가리킬 수 있다. (그림에서도 화살표가 안쪽으로만 향함)
2. 내부의 어떤 것도 외부의 원 안에 있는 것에 대해서는 전혀 알 수 없다.
3. 외부의 원 안에 있는 어떤 것도 내부의 원 안의 코드에서 언급되어서는 안된다. (함수, 클래스, 변수 등)

 

종속성 규칙의 핵심은 안쪽 원은 바깥쪽 원에 대해 아무것도 몰라야 한다는 것! 입니다.

즉, 내부 레이어는 외부 레이어에 의존성(dependency)를 가지면 안됩니다.

 

각 레이어에 대해 안쪽 원부터 하나씩 살펴봅시다.

Entities

전체의 비즈니스 규칙들을 캡슐화합니다. 엔티티는 메서드를 가진 객체일 수도 있고, 데이터 구조 및 함수의 집합일 수도 있습니다.

애플리케이션의 비즈니스 객체들(business objects)로, 가장 일반적이고 높은 수준의 규칙들을 캡슐화합니다.

해당 계층은 가장 덜 변경되며, 외부의 변경에도 영향 받지 않는 레이어입니다.

 

번역을 하니 설명이 어렵게 되어있는 것 같은데, 한마디로 엔티티는 데이터 구조 및 함수의 집합입니다.

뷰나 비즈니스 로직에 사용되는 데이터(비즈니스 모델)라고도 할 수 있을 것 같은데요,

외부 로직의 변경에도 데이터 자체는 거의 변하지 않기 때문에 가장 일반적이고 높은 수준의 규칙이라고 말할 수 있을 것 같습니다.

Use Cases

해당 계층에서는 애플리케이션의 특정 비즈니스 규칙을 포함합니다.

엔티티와의 데이터 흐름을 조정하고, 해당 엔티티가 Use Case의 목표를 달성하도록 지시하는 역할을 합니다.

Use Case의 변화는 안쪽 원인 Enitity에 영향을 미치지 않으며, Use Case 또한 데이터베이스, UI 혹은 프레임워크와 같은 외부의 변화에 영향받지 않습니다. (종속성 규칙) 

하지만, 앱 전체의 동작에 대한 변경은 Use Case에 영향을 미칠 수 있습니다. (외부 레이어가 아니라 사용자 시나리오 변경이니까..이런 뜻인 것 같습니다...)

 

Use Case는 비즈니스 로직이 위치하는 곳으로, 엔티티로 들어오고 나가는 데이터 흐름을 조정하는 역할을 합니다.

사실 MVVM 구조에서 Use Case를 구성하는 것이 제일 고민되는 부분이라고 생각하는데요,, 단순히 뷰와 뷰모델의 다리 역할을 하는 것인지...이 부분은 적용해보면서 더 고민해봐야겠습니다! (MVVM+Clean Architecture 관련 게시글로 내용 정리해보도록 할게요)

Interface Adapters

Controllers, Gateways, Presenters를 포함하는 레이어로, Presentation Layer 라고 부르기도 합니다.

데이터를 Use Case 및 Enitity에 가장 편리한 포맷에서 데이터베이스나 웹과 같은 외부에서 편리한 포맷으로 변환해주는 역할을 하는 계층입니다. 안쪽 원의 코드는 데이터베이스에 대해 몰라야 하는데, 해당 레이어에서 알맞은 형식으로 매핑해줄 수 있습니다.

Frameworks and Drivers

가장 바깥쪽 레이어로, DB, UI, 프레임워크 등과 같은 도구와 프레임워크로 구성됩니다.

Only Four Circles?

여기까지 4개의 레이어에 대해 정리해보았는데, 계층은 꼭 4개로만 구성되어야 하나요?

정답은 당연히 아닙니다! 레이어가 몇개로 구성되든 dependency rule 만 적용되면 됩니다.

즉, 소스 코드 의존성이 안쪽으로만 향하면 된다는 뜻이겠죠??

기억해야 할 것은 안쪽으로 갈 수록 추상화 수준이 증가한다는 것입니다.

안쪽으로 갈수록 추상적이고 일반적인 고수준의 정책이 위치하고, 바깥으로 갈수록 저수준의 구체적인 세부사항이 존재합니다.

Crossing boundaries

원의 경계를 넘나드는 방법에 대한 예시가 다이어그램 우측 하단에 포함되어있습니다.

선을 따라가보면 Controller -> Use Case -> Presenter 의 플로우로 실행되고 있는데요,

Use Case가 더 안쪽 원인데 Use Case에서 Presenter로 실행되는 플로우가 가능할까요?

Dependency Rule에 위배되는 것 아닌가,, 할 수 있는데!

 

DIP(의존 관계 역전 법칙)으로 안쪽에서 바깥쪽으로 간접 접근이 가능하게 할 수 있습니다!

Use Case가 안쪽 원에 있는 인터페이스(= Use Case Output Port)를 호출하도록 하고 바깥쪽 원에있는 Presenter에게 이를 구현하도록 하는 방식을 통해 원하는 플로우로 실행이 가능합니다. 이렇게 하면 바깥쪽 레이어인 Presenter에 대해 몰라도 인터페이스를 통해 접근이 가능한 것입니다. (iOS에서는 프로토콜로 구현 가능)

Clean Architecture의 장점

소프트웨어를 여러 층으로 분리하고 종속성 규칙(dependency rule)을 준수함으로써, 역할 분리가 명확한 코드로 시스템을 설계할 수 있습니다. 역할 분리가 명확한 코드는 테스트가 편리하고 확장과 수정에 유연하기 때문에 전체적으로 유연한 설계가 될 것 같네요!

---

밥아저씨의 블로그 글을 번역하면서 클린 아키텍처의 개념과 각 레이어에 대해 정리해보았는데요,

다음 게시글에서는 예제 코드 분석을 통해서 구체적인 코드를 살펴보며 이해해보도록 하겠습니다!