[TIL] 클린 아키텍쳐(The Clean Architecture)

오늘은 클린 아키텍쳐에 대해 읽어봤으며, 고수가 쓰신 글을 번역한 수준에 불과하다 : )

 

• Hexagonal Architecture by Alistair Cockburn and adopted by Steve Freeman, and Nat Pryce in their wonderful book Growing Object Oriented Software
• Onion Architecture by Jeffrey Palermo
• Screaming Architecture from a blog of mine last year
• DCI from James Coplien, and Trygve Reenskaug.
• BCE by Ivar Jacobson from his book Object Oriented Software Engineering: A Use-Case Driven Approach

 

위 아키텍처들은 세부적으로는 다소 차이가 있지만 대체적으로 매우 유사하다. 이들은 모두 같은 목표를 가지고 있는데, 그것은 바로 관심사의 분리이다. 소프트웨어를 계층으로 분할하여 이 목표를 달성한다. 각 계층에는 저어도 하나 이상의 비즈니스 로직용 계층과 인터페이스용 계층이 존재한다. 이러한 아키텍처들은 다음과 같은 성격을 나타낸다.

 

1. 프레임워크와 무관하다.
   외부 라이브러리에 의존적이지 않기 때문에 제한된 조건을 가진 시스템에도 프레임워크를 도구로 사용할 수 있다.
2. 테스트하기 쉽다.
   비즈니스 로직을 UI, 데이터베이스, 웹 서버 또는 다른 외부 요소 없이 테스트할 수 있다.
3. UI와 무관하다.
   UI는 시스템의 나머지 부분을 변경하지 않고도 쉽게 변경할 수 있다. 예를 들어 웹 UI를 비즈니스 규칙을 변경하지 않고 콘솔 UI로 바꿀 수 있다.
4. 데이터베이스와 무관하다.
   Oracle, SQL Server, Mongo 또는 기타 DB를 대체 할 수 있다. 비즈니스 로직이 DB에 바인딩되어 있지 않다. 예를 들어 fixture, dummy, in-memory, json 등을 통해 테스트할 정도의 가상 데이터만을 만들 수 있다.
5. 외부 기관과 무관합니다.
   여러분의 비즈니스 상황을 외부에서는 전혀 알지 못한다. 이 부분은 정확히 모르겠지만, 내 생각은 이러하다. 기관 또는 Open API 서버의 중단 등 외부 의존성을 가지고 있는 모든 요소들에 문제가 생겨도 무관하다는 의미로 해석 된다.

 

The Dependency Rule

원 각각은 소프트웨어의 다른 영역을 나타낸다. 외부 원은 메커니즘이고, 내부 원은 정책들이다. 위 그림에서 중요한 점은 이 아키텍처를 작동시키는 종속성 규칙입니다. 이 규칙은 소스 코드 종속성이 안쪽만 가리킬 수 있다고 말한다. 내부 원 안에 있는 그 무엇도 외부 원 안에 있는 어떤 것에 대해 전혀 알 수 없다는 점을 기억해야 한다. 이 부분이 의미하는 바가 바로 관심사의 분리이며, 클린 아키텍쳐를 이루는 중요한 개념이다.

 

Entities

Entities encapsulate Enterprise wide business rules.

Entity는 메소드가 있는 객체이거나 데이터 구조 및 함수의 집합이며, 대부분의 경우 엔티티는 비즈니스 객체다. Entity는 가장 일반적이고 높은 수준의 규칙을 캡슐화하기 때문에 외부의 요소들이 변할 때 함께 변경해야할 가능성이 가장 적다. 예를 들어, 이러한 개체가 페이지 탐색 변경이나 보안의 영향을 받지 않을 것으로 예상할 수 있는 것처럼 말이다.

 

중요한 것은 특정 애플리케이션에 대한 어떠한 운영상의 변경도 엔티티 계층에 영향을 미쳐서는 안 된다는 점이다. 이 계층은 Entity에 어떤 데이터를 담을 것인가에 대한 관심사만을 가지고 있다.

 

Use Cases

The software in this layer contains application specific business rules.

시스템의 모든 Use Cases를 캡슐화하고 구현한다는 점에서 MVC Spring에서 Service로 여겨진다. 이러한 Use Case는 Entity로부터의 데이터 흐름을 전두지휘하며, Use Cases의 목표를 달성하기 위해 전사적인 비즈니스 로직이 구현된다. 이 계층은 Entity에 담겨진 데이터를 어떻게 가공할 것인가에 대한 관심사만을 가지고 있다.

 

이 계층의 변화가 Entity에 영향을 미치면 안 되며, 데이터베이스나 UI 또는 공통 프레임워크와 같은 외부 요소의 변경에 영향을 받아서도 안 된다. 이 계층은 그러한 우려로부터 충분히 격리되어야 한다.

 

하지만, 애플리케이션 작동에 대한 변경사항이 Use Cases와 이 계층의 소프트웨어에 영향을 미칠 것으로 예상한다. Use Case의 세부 정보가 변경되면 이 계층의 일부가 영향을 받을 수 있다.

 

Interface Adapters

MVC 아키텍처를 포함하는 것은 이 계층이다. Presenters, Views, Controllers는 모두 여기에 속한다. 모델은 컨트롤러를 통해서 뷰로의 흐름에서 사용되는 데이터 구조체이다. 서비스로 전달된 다음 비즈니스 로직 처리 후  발표자 및 뷰로 되돌아오는 구조가 가장 흔하다. MVC Spring Framework를 생각하면 가장 쉽게 이해가 될 계층이다.

 

추가적으로, 이 계층에서 데이터는 entity와 use case 자체 형태에서 사용중인 프레임워크에 가장 편리한 형태로 변환된다. 특히 DB를 특정 짓자면, 이 원 안에 있는 어떤 코드도 DB에 대해 알 수 없다. DB가 SQL DB인 경우 모든 SQL은 이 계층으로 제한되어야 한다.

 

또한, 이 계층에는 외부 서비스와 데이터를 내부 서비스와 엔티티에서 사용할 수 있는 형태로 변환하는데 필요한 어댑터도 존재한다.

 

Frameworks and Drivers

가장 바깥쪽 계층은 일반적으로 데이터베이스, 웹 프레임워크 등과 같은 프레임워크와 도구로 구성된다. 이 층은 모든 세부적인 것들을 포함한다. 세부적인 것들이 무엇일까? 일단 아래의 글귀와 예시를 읽어보자.

 

그들이 우리의 어플리케이션에 가능한 한 거의 해를 끼치지 않는 곳에 보관합니다.
웹은 세부 사항이고, 데이터베이스도 세부사항이다.

 

예시를 본 후, 다음과 같이 이해했다. 우리의 어플리케이션의 문제가 아니라면, 갑자기 WEB에 문제가 생기거나 외부 DB가 죽어도 우리의 어플리케이션은 살아 있어야 한다. 그들과 관심사가 분리되어 있기 때문이다.

 

 

 

 

- 출처 -

 

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

"Uncle Bob"이라 불리는 Robert Cecil Martin은 미국 소프트웨어 엔지니어, 강사 및 베스트셀러 작가다.
많은 소프트웨어 디자인 원칙을 개발하고 영향력 있는 Agile Manifesto의 창립자로서 가장 잘 알려져 있다.

Clean Coder Blog

 

 

틀린 내용이 있다면, 알려주시면 감사하겠습니다 ; )

 

 

2021. 5. 27(목) TIL