[Architecture] 3. 클린 아키텍처(Clean Architecture)

이번 챕터에서는 두 가지 아키텍처 스타일 중 첫번째 클린 아키텍처에 대해 이야기 한다.

 

1. 클린 아키텍처

로버트 C. 마틴이 정립한 용어로, 클린 아키텍처에서는 설계가 비즈니스 규칙의 테스트를 용이하게 하고, 비즈니스 규칙은 프레임워크, 데이터베이스, UI 기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적일 수 있다고 이야기 한다.

 

이는 도메인 코드가 바깥을 향하는 어떤 의존성도 없어야 함을 의미하며, 대신 의존성 역전의 원칙의 도움으로 모든 의존성이 도메인 코드를 향한다.

 

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

 

클린 아키텍처에서 가장 주요한 규칙은 의존성 규칙으로, 계층 간의 모든 의존성이 안쪽을 향해야 한다는 것이다.

 

아키텍처 코어에는 유스케이스에서 접근하는 도메인 엔티티가 존재하며, 유스케이스는 단일 책임을 갖기 위해 조금 더 세분화되어 있다.

도메인 엔티티 코어 주변으로 비즈니스 규칙을 지원(영속성을 제공하거나 UI를 제공하는 것 등)하는 애플리케이션의 다른 모든 컴포넌트들을 확인할 수 있으며, 바깥쪽 계층들은 다른 서드파티 컴포넌트에 어댑터를 제공할 수 있다.

 

도메인 코드에서는 어떤 영속성 프레임워크나, UI 프레임워크를 사용하는지 알 수 없기 때문에 특정 프레임워크에 특화된 코드를 가질 수 없고 비즈니스 규칙에 집중할 수 있어 도메인 코드를 자유롭게 모델링할 수 있어 도메인 주도 설계(Domain-Driven Design, DDD)가 가능하다.

 

하지만 클린 아키텍처는 도메인 계층이 영속성이나 UI 같은 외부 계층과 철저하게 분리되어야 하므로 애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수해야 한다.

 

예를 들어 영속성 계층에서 ORM(object-relational mapping, 객체-관계매핑) 프레임워크를 사용한다고 가정하였을 때, 도메인 계층은 영속성 계층을 모르기 때문에 도메인 계층에서 사용한 엔티티 클래스를 영속성 계층에서 함께 사용할 수 없고, 두 계층에서 각각 엔티티를 만들어야 한다.

즉, 도메인 계층과 영속성 계층이 데이터를 주고 받기 위해 두 엔티티를 서로 변환해야 한다는 것을 뜻하며 이는 다른 계층들 사이에서도 마찬가지다.

 

하지만 이것은 바람직한 일이다.

이것이 바로 도메인 코드를 프레임워크에 특화된 문제로부터 해방시키고자 했던, 결합이 제거된 상태이기 때문이다.

 

2. 결론

로버트 C. 마틴의 클린 아키텍처는 다소 추상적이기 때문에 조금 더 깊게 들어가서 클린 아키텍처의 원칙들을 조금 더 구체적으로 만들어주는 '육각형 아키텍처에'에 대해 다음 챕터에서 정리하겠다.

 

Reference.

만들면서 배우는 클린 아키텍처

https://wikibook.co.kr/clean-architecture-ebook/

만들면서 배우는 클린 아키텍처 (ebook): 자바 코드로 구현하는 클린 웹 애플리케이션