Portfolio

간단한 게임이 UI, 업무 규칙, 데이터베이스 로만 구성된다 했을 때 UI는 플레이어가 입력한 메시지를 모두 게임 규칙으로 전달하고 게임 규칙은 게임의 상태를 영속성을 가지는 특정한 데이터 구조로 저장한다. 하지만 정말 이게 전부일까?

게임 규칙과 UI를 분리하여 다양한 언어로 발매할 수 있게 만든다면?

의존 방향이 모두 안쪽으로 흐르기 때문에 게임 규칙은 어떤 종류의 인간 언어가 사용되는지 알지도 못하고 신경 쓸 필요가 없다. 그렇기 때문에 게임 규칙을 재사용할 수 있게 된다.

데이터베이스도 마찬가지로 Ram이건 메모리이건 신경 쓸 필요가 없을 것 이다.

위의 맥락만이 중요한 아키텍처 경계를 모두 발견한 것일까?

UI가 shell창이였지만 텍스트 메시지나 채팅 애플리케이션을 사용하고 싶다면??

위에서는 보지 못했던 변경의 축에 의해 정의되는 아키텍처 경계를 생각할 수 있게 된다.

언어를 통신 메커니즘으로 부터 경리하려면 아래와 같은 그림이 될 것이다.

API는 구현하는 쪽이 아닌 사용하는 쪽에 정의되고 소속된다.

→ Language가 추상 클래스고 그 안에 Game Rules가 있는 말인가?

GameRules를 들여다 보면 …. ← 이쪽 이해가 잘 안됩니다!

이 모든 경우에 해당 Boundary 인터페이스가 정의하는 API는 의존성 흐름의 상위에 위치한 컴포넌트에 속한다.

결국 GameRules는 최상위에 놓이게 된다. (최상위 수준의 정책을 가지고 있는 컴포넌트이므로)

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

그럼 데이터 흐름이 두개로 끝일까?

움퍼스 사냥 게임을 네트워크상에서 여러 사람이 함께 플레이할 수 있게 해야한다면?

네트워크 컴포넌트를 추가해야 할 것이다.

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

결국 모든 흐름이 상단의 단일 컴포넌트에서 서로 만난다고 생각할 수 있지만 현실은 더 복잡하다.

GameRules 컴포넌트는 고수준 정책이지만 그 보다 높은 수준에는 또 다른 정책 집합이 존재한다.

그럼 이것이 아키텍처 경계일까?

처음에는 잘 모르겠지만 마이크로서비스까지 추가하였을 땐 완벽한 형태의 아키텍처 경계가 존재한다.

아키텍처 경계가 어디에나 존재한다.

하지만 아키텍트는 추상화가 필요할것이라고 미리 예측해서도 안되고 경계를 나누지 않아도 안된다.

결국 비용을 산정하고 어디에 경계를 두어야 하고 완벽한 경계와 부분적 경계는 무엇인지를 결정해야한다.

하지만 처음부터 이러한 경계는 잘 보이지 않기 때문에 관찰하면서 경계가 존재하지 않아 생기는 마찰의 어렴풋한 첫 조짐을 마주치게 된다면 비용을 산정해서 경계 구현 비용이 무시해서 생기는 비용보다 적어지는 그때 경계를 구현해야 한다.

25장 계층과 경계