[Clean Architecture] 25. 계층과 경계

시스템이 세 가지 컴포넌트(UI, 업무 규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다. 몇몇 단순한 시스템에서는 이 정도로 충분하다.

하지만 대다수의 시스템 컴포넌트의 개수는 이보다 훨씬 많다.

움퍼스 사냥 게임

• GO EAST, SHOOT WEST와 같은 단순한 명령어를 사용한다.
• 플레이어는 명령어를 입력하며, 컴퓨터는 플레이어가 보고 듣고 경험한 것들로 응답한다.

텍스트 기반 UI는 유지하되, 게임 규칙과 UI를 분리해서 제품을 여러 시장에서 다양한 언어로 발매한다고 가정해보자.

 

• 이 규칙은 언어 독립적인 API로 UI 컴포넌트와 통신할 것이고 UI는 API를 사람이 이해할 수 있는 언어로 변환할 것이다.

 

 

소스 코드 의존성을 적절히 관리하면 어떤 언어를 UI가 사용하더라도 게임 규칙을 재사용 할 수 있다.

 

 

게임의 상태를 영속적인 저장소에 유지한다고 가정하자. 그게 클라우드 혹은 단순 RAM등 여러가지일 수 있다. 게임 규칙이 이러한 세부 사항을 알지 않기를 바란다.

역시 API를 생성해 게임 규칙이 데이터 저장소 컴포넌트와 통신할 때 사용하도록 만든다.

 

의존성 규칙을 준수할 수 있도록 의존성이 적절한 방향을 가리키게 만든다.

 

클린 아키텍처?

UI에서 언어가 유일한 변경의 축은 아니다. 예를 들면 텍스트를 주고받는 메커니즘을 다양하게 만들고 싶을 수 도 있다.(텍스트 메시지나 채팅 어플리케이션을 사용할 수 있음)

따라서 이 변경의 축에 의해 정의 되는 잠재된 아키텍처 경계가 있을 수 있음.

 

아마도 해당 경계를 가로지르는, 그래서 언어를 통신 매커니즘으로부터 격리해야하는 API를 생성해야 할 수도 있다.

 

 

• 점선 테두리는 API를 정의하는 추상 컴포넌트를 가리키며, 해당 API는 추상 컴포넌트 위나 아래의 컴포넌트가 구현한다.
• GameRules는 GameRules가 정의하고 Language가 구현하는 API를 통해 Language와 통신함
• Language는 Language가 정의하고 Text Dilivery가 구현하는 API를 이용해 TextDilivery와 통신함

API는 사용하는 쪽에 정의되고 소속된다.

 

English, SMS, CloudData와 같은 변형들은 추상 API 컴포넌트가 정의하는 다형적 인터페이스를 통해 제공되고, 실제로 서비스하는 구체 컴포넌트가 이를 구현

 

• 예를들어 Language가 정의하는 다형적 인터페이스는 English, Spanish가 구현

이러한 변형들을 모두 제거하고 순전히 API 컴포넌트만 집중하면 아래와 같은 다이어그램

 

 

• GameRules는 최상위에 놓인다.
• GameRules는 최상위 수준의 정책을 가지는 컴포넌트이므로 이치에 맞는 배치

 

정보가 흐르는 방향

 

• 사용자 입력 -> TextDelivery -> Language(GameRules에 적합한 명령어로 번역) -> GameRules -> 우측 하단의 DataStorage
• GameRules 출력 -> Language(적절한 언어로 번역) -> TextDelivery -> 사용자 output

이 구성은 데이터 흐름을 두 개의 흐름으로 효과적으로 분리한다.

 

• 왼쪽은 사용자와의 통신에 관여
• 오른쪽은 데이터 영속성에 관여

GameRules는 두 흐름이 모두 거치게 되는 데이터에 대한 최종적 처리기가 된다.

 

흐름 횡단하기

네트워크상에서 여러 사람이 함께 플레이한다고 가정하자.

 

 

이 구성은 데이터 흐름을 3개의 흐름으로 분리하며, 이들 흐름은 모두 GameRules가 제어한다.

 

시스템이 복잡해질 수록 컴포넌트 구조는 더 많은 흐름으로 분리될 것이다.

 

화살표의 방향은 데이터 흐름이 아니고 소스코드 의존성