clean_architecture.md

The Clean Architecture

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

소프트웨어 설계의 다양한 관점에 있어서 공통된 부분 - 관심사 분리. 일반적으로 하나의 소프트웨어를 여러개의 계층 구조로 변경하여 관심사 분리를 수행함. 각 레이어는 최소 하나 이상의 비즈니스 룰과 인터페이스를 정의함.

그동안 논의되어온 다양한 아키텍쳐는 주로 아래와 같은 특징이 있음

1. 프레임워크 독립성. 아키텍쳐는 라이브러리나 프레임워크에 무관하게 독립적으로 설계 가능해야함. 이를 통해 프레임워크와 라이브러리를 단순히 툴의 하나로 사용할 수 있게 하고 의존적이지 않게 함.

2. 쉬운 테스트. 비즈니스 룰을 테스트 하고자 하는 경우 UI, 데이터베이스, 웹 서버 등과 같은 비즈니스 룰 외의 외부 요소와 무관하게 테스트 할 수 있어야 함.

3. UI 독립성. UI를 변경할 때 다른 요소들을 변경하지 않고 쉽게 UI만 변경 가능해야 함. 웹 UI 애플리케이션을 손 쉽게 console UI 애플리케이션으로 변경하고, 비즈니스 룰과 관련된 코드는 전혀 변경하지 않을 수 있는 상태가 좋은 예제.

4. 데이터베이스 독립성. 원하는 시점에 원하는 데이터베이스로 마음대로 변경 가능해야 함.

5. 외부 요소와의 독립성. 기본적으로 하나의 소프트웨어는 외부 요소에 대한 정보를 전혀 모른다고 가정해야 함.

위의 그림으로 요점을 간략하게 나타낼 수 있음.

The Dependency Rule

위의 그림에서 하나의 원은 소프트웨어 내에서 분리된 각각의 역할을 나타냄. 일반적으로 이를 잘 적용할 수록 점점 더 고수준의 소프트웨어를 완성시킬 수 있음. 원의 외부와 가까울 수록 메커니즘의 표현을 의미함. 원의 내부와 가까울 수록 정책 (policy)를 의미함.

클린 아키텍쳐를 구성하는 가장 기본적인 의존성 규칙은, 각 레이어는 더 안쪽 원의 레이어에만 의존해야 한다는 것. 안쪽의 원은 바깥 쪽의 레이어에 대해 전혀 알지 못한 상태로 동작할 수 있어야 함. 안쪽 원을 표현하는 코드에는 바깥 쪽 원을 표현하는 코드의 그 어떤 (클래스, 함수, 변수 등등) 코드들도 사용해서는 안됨. 외부에서 사용하는 데이터 형식 또한, 내부에서 사용해서는 안됨. 이를 통해서 외부 원의 변경이 내부 원의 변경으로 이어지지 않도록 설계 할 수 있음.

Entities

엔티티는 전사적 비즈니스 규칙을 캡슐화 하는 역할을 함. 메소드를 가진 객체, 데이터 구조의 집합, 다양한 함수 등이 엔티티 역할을 수행할 수 있음. 전사적으로 사용되는 다양한 소프트웨어가 하나의 엔티티를 수정하지 않고 사용할 수만 있다면, 어떤식으로 구현하든 상관 없음.

전사적 소프트웨어를 구현하는게 아니라, 단일 애플리케이션을 구현하는 거라면, 앱 내의 비즈니스 객체를 표현하면 됨. 엔티티를 구현할 때는 서비스 내에서 가장 일반적인 형태로 고수준의 규칙을 표현해야함. 외부 요소가 변경되더라도 거의 변하지 않고, 정말 필수적인 최후의 경우에만 엔티티 코드가 변경되도록 분리해야함. 예를 들어, 페이지 이동이나 보안 규칙이 변한다고 해서 엔티티의 코드가 변화해서는 안됨. 앱의 그 어떤 레이어에서 발생하는 변화도 엔티티에 영향을 주지 않도록 주의.

Use Cases

유즈 케이스 레벨의 코드는 지금 구현하고자 하는 앱에 특화된 비즈니스 로직이 들어감. 현재 구현하는 시스템의 모든 유즈 케이스를 구현하고 캡슐화 해야 함. 앱 내의 엔티티를 전사적인 레벨의 비즈니스 룰과 연결하는 역할을 함.

당연히 이 레이어의 변화가 엔티티에 영향을 줘서는 안됨. 또한, 유즈 케이스 레이어 외부의 다른 레이어, 즉 데이터베이스, UI, 프레임워크 등이 유즈 케이스 레이어에 영향을 줘서도 안됨. 반드시 관심사 분리가 되어야 함.

유즈 케이스는 앱 특화의 비즈니스 룰을 구현하는 것이므로, 앱의 사용 방식이나 비즈니스 룰 변화에는 당연히 유즈케이스 변화도 발생해야함. 유즈 케이스의 상세 동작 방식을 이 레이어에서 구현하면 됨.

Interface Adapters

유즈케이스와 엔티티에서 사용하는 데이터 포맷을 데이터베이스나 웹서비스와 같은 외부 요소에서 사용하기 편한 모델로 변경해주는 어댑터들의 집합이다. GUI 앱에서 흔히 말하는 MVC 아키텍쳐와 같은 구조가 이 레이어에 포함된다. Presenter, View, Controller 를 모두 이곳에서 작성하면 된다. 모델은 컨트롤러에서 유즈 케이스로 전달하는 단순한 데이터 구조이고, 유즈 케이스에서 Presenter와 View 로 전달할 때도 동일하게 사용된다.

데이터베이스로 보내는 데이터 포맷으로 변경할 때도 동일하게 이 레이어에 코드를 작성하면 된다. 다만, 이 레이어의 코드들은 데이터베이스의 동작원리는 실제 데이터베이스 데이터 모델을 알아서는 안된다. SQL 을 사용하는 데이터베이스가 대상일 경우, SQL 자체에 관련된 로직만 이 레이어에 작성하고, 작성된 SQL 또한 독립된 데이터베이스 인터페이스 어댑터 코드에 구현되어야 한다. 특정 SQL 데이터베이스에 대한 기능이 포함되어서는 안된다.

위의 예시 외에도 내부의 자료구조를 외부와 통신할 때 사용되는 데이터 변환 코드는 모두 이 계층에 구현한다.

Frameworks and Drivers

가장 바깥 원은 데이터베이스, 웹 프레임워크 등과 같은 다양한 툴들의 집합이다. 보통 안쪽 원과 통신하는 코드만 작성하면 된다.

실제 웹의 상세 코드, 데이터베이스의 상세 코드 등도 이곳에서 작성한다.

Only Four Circles?

여기서 보여준 원형 구조는 도식적으로 클린 아키텍쳐를 표현한 것 뿐이다. 이 보다 더 많은 계층 구조가 필요한 경우도 있다. 다만, Dependency Rule 만은 반드시 지켜져야 한다. 코드들의 의존성은 항상 안쪽으로만 향해야 한다. 안쪽 원을 향할 수록 추상화가 심화된다고 보면 되고, 바깥 원을 향할 수록 더 자세한 코드가 들어간다고 보면된다.

Crossing boundaries

다이어그램의 우하단에 보면 원의 경계선을 지나가거나 통신하는 예제가 있다. 예제에서는 Controller와 Presenter 가 내부 계층인 Use case와 통신하는 방식을 보여준다. Controller에서 시작해서 use case로 이동한 다음, presenter에서 결과를 처리하고 있다. UML의 의존성을 자세히 보면, 한쪽 방향으로만 흐르는 것을 알 수 있다. Controller는 Use case Input port의 구현체를 사용 하여 use case를 전달하고, Presenter는 use case output port의 구현체를 작성한뒤 use case가 세부 내용을 모르고 사용할 수 있도록 한다. 주의 점은, 두 계층을 연결하는 interface/port/adapter는 모두 내부 계층인 use case에서 관리한다는 점이다.

이러한 방식을 의존성 역전 (Dependency Inversion Principle) 이라고 한다. 자바와 같은 언어를 예로 들면, 상속관계의 플로우를 데이터 플로우와 정반대로 설계하면 된다.

Use case가 presenter를 호출해야 하는 상황을 보자. Dependency Rule 에 따라 Use case가 직접 presenter를 호출해서는 안된다 (out -> in만 해야하는 규칙에 위배됨.) 이를 해결하기 위해 use case 계층에 interface를 선언 한다 (그림에서는 Use Case Output Port). Presenter는 이에 대한 구현체를 만들어 둔다. Use case는 자신의 선언한 interface만을 사용하여 presenter와 독립적인 코드가 되도록 구현할 수 있다.

클린 아키텍쳐의 모든 계층 경계를 지나가는 코드들은 위의 예제와 동일하게 구현하면 된다. 동적 다형성을 활용하면 이를 쉽게 구현할 수 있고, dependency rule을 위배하지 않게 된다.

What data crosses the boundaries

계층 경계를 지나는 데이터 구조는 일반적으로 매우 단순한 구조여야 한다. DTO (Data Transfer Object)나 간단한 구조체를 사용해도 된다. 경우에 따라서는 함수 호출의 단순매개변수만 필요할 때도 있다. 중요한 점은, 완전히 독립된 (고립된) 단순한 데이터 구조여야 한다는 것이다. 내부에서 사용하는 Entity나 외부에서 사용하는 Database row 등과 같은 직접적인 객체들을 전달해서는 안된다. 데이터 전달도 역시나 Dependency Rule을 위배하지 않아야 한다.

예를 들어, 대부분의 데이터베이스 프레임워크 들은 query 용청에 대해 데이터베이스가 표현하기 편한 포맷의 데이터를 반환한다. 이를 RowStructure라고 하자. 프레임워크 레이어에서 받아온 이 구조를 그대로 안쪽 계층으로 전달해서는 안된다. 이는 외부의 구조를 내부의 계층이 직접 알고 사용하는게 되므로, 데이터베이스를 변경하는 등의 외부 변화에 내부 계층이 영향을 받게 된다.

그러므로 외부에서 내부로 데이터를 전달하는 경우에는 반드시 내부에서만 사용하는 데이터 구조에 맞게 변경하여 전달해야 한다.

Conclusion

클린 아키텍쳐 규칙을 지키는 것은 크게 어렵지 않고, 소프트웨어를 고수준으로 유지하는데 큰 도움을 준다. 소프트웨어를 다양한 계층 구조로 나누고, Dependency Rule을 준수하면, 자연적으로 테스트하기 쉽고 이에 따라 다양한 이점을 갖는 소프트웨어를 만들 수 있다. 외부 요소의 그 어떤것이 변화/삭제 되더라도 최소한의 변경으로 소프트웨어를 유지할 수 있다.