움퍼스 사냥게임
다양한 언어로 지원되는 게임이며 게임 규칙은 어떤 언어 UI로 사용 되더라도 의존성을 잘 관리하면 그림과 같이 게임임 규칙을 재사용할 수 있음.
게임상태를 저장하는 컴포넌트가 있더라도 마찬가지로 의존성 관리가 되어 게임 규칙을 의존하는 형태. (당연히 고수준인 규칙을 의존하는 형태)
클린 아키텍처?
UI에서 언어가 유일한 변경의 축은 아니기 때문에 변경의 축에 의해 정의 되는 잠재된 아키텍처 경계가 있을 수 있음. 예를 들면 텍스트를 주고받는 메커니즘을 다양하게 만들고 싶을 수 도 있음.
이 모든 경우에 해당 Boundary 인터페이스가 정의하는 API는
의존성 흐름의 상위에 위치한 컴포넌트에 속함.
English, SMS 와 같은 변형들을 모두 제거하고 API 컴포넌트만 집중한 단순화된 그림임.
모든 화살표가 최상위 수준의 정책인 GameRules를 향함. 이치에 맞는 배치임.
정보가 흐르는 방향을 보면
데이터의 흐름을 두개로 분리할 수 있음.
- 사용자와의 통신에 관여.
- 데이터 영속성에 관여.
즉, 두 흐름을 모두거치는 GameRules는 데이터에 대한 최종적인 처리기가 됨.
흐름 횡단하기
데이터 흐름은 더 추가될 수 있음.
움퍼스 사냥게임의 온라인 지원된 경우의 다이어그램
즉, 시스템이 복잡해질수록 컴포넌트 구조는 더 많은 흐름으로 분리됨.
흐름 분리하기
게임 규칙중 일부인 지도 관련 메커니즘을 처리하는 MoveManagement를 추가한 경우
지도규칙에 의해 플레이어의 지도 관련 사건을 처리함.
게임중 구덩이에 빠지면 MoveManagement은 이를 판단한 후 고수준인 PlayerManagement정책에게 알려 PM에서 플레이어의 승리 여부 상태를 결정해줌.
MoveManagement 와 PlayerManagement는 사이에는 아키텍처 경계가 생김.
결론
작은 예제 조차 아키텍처 경계가 존재하며, 아키텍트는 아키텍처 경계가 언제 필요한지를 신중히 파악해야함.
'📚 Book > Clean Architecture' 카테고리의 다른 글
27장 '크고 작은 모든' 서비스들 (0) | 2020.02.22 |
---|---|
26장 메인(Main) 컴포넌트 (0) | 2020.02.22 |
24장 부분적 경계 (0) | 2020.02.22 |
23장 프레젠터와 험블 객체 (0) | 2020.02.22 |
22장 클린 아키텍처 (0) | 2020.02.22 |