계층과 경계

시스템 컴포넌트 크게 3가지(UI / 업무규칙 / 데이터베이스)로 구성된다고 생각할 수 있으나, 실제로 대규모 시스템에서는 그 이상이 될수도 있다.

움퍼스 사냥 게임

• 다양한 언어로 지원되는 게임이며 게임 규칙은 어떤 언어 UI로 사용 되더라도 의존성을 잘 관리하면 그림과 같이 게임임 규칙을 재사용할 수 있음.

• 게임상태를 저장하는 컴포넌트가 있더라도 마찬가지로 의존성 관리가 되어 게임 규칙을 의존하는 형태이다.

클린 아키텍처?

• UI에서 언어가 유일한 변경의 축은 아니기 때문에 텍스트를 주고받는 메커니즘을 다양하게 만들고 싶을 수도 있다. 따라서 아래 그림과 같이 해당 변경의 축에 의해 정의되는 아키텍처 경계를 살펴볼 수 있다.

이미지 출처 : https://hwannny.tistory.com/44

• 점선으로 된 테두리는 API를 정의하는 추상 컴포넌트를 가리키며, 해당 API는 추상 컴포넌트 위나 아래의 컴포넌트가 구현한다.
• 이 모든 경우에 해당 Boundary 인터페이스가 정의하는 API는 의존성 흐름의 상위에 위치한 컴포넌트에 속한다.

• 정보가 흐르는 방향을 보면 데이터 흐름을 두 개의 흐름으로 효과적으로 분리한다.
  • 왼쪽의 흐름은 사용자와의 통신에 관여
  • 오른족의 흐름은 데이터 영속성에 관여.
• 즉, 두 흐림이 GameRules에서 만나, GameRules는 두 흐름이 모두 거치게 되는 데이터에 대한 최종적인 처리기가 된다.

흐름 횡단하기

• 데이터 흐름이 추가 될 수 있다.
• 네트워크를 통한 여러 사람과의 플레이를 위해 네트워크 컴포넌트를 추가함. → 시스템이 복잡해질수록 컴포넌트 구조는 더 많은 흐름으로 분리될 것이다.
  

흐름 분리하기

• 모든 흐름이 상단의 단일 컴포넌트에서 만나는 것은 아니다.
• GameRules 컴포넌트가 플레이어의 이동 관련된 정책(Move Management)과 그보다 고수준 정책인 플레이어 정책(Player Management)이 있다면 GameRules 컴포넌트를 아래와 같이 분리할 수도 있다.

결론

• 이런 작은 예제 속에서도 아키텍처 경계는 어디에나 존재할 수 있다.