클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 5부 : 아키텍처 (25장)

[25장] 계층과 경계

시스템이 세 가지 컴포넌트(UI, 업무 규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다. 예를 들어 간단한 컴퓨터 게임을 생각해보자. UI는 플레이어가 입력한 메시지를 모두 게임 규칙으로 전달한다. 게임 규칙은 게임의 상태를 영속성을 가지는 특정한 데이터 구조로 저장한다.

 

[움퍼스 사냥 게임]

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

우리는 게임 규칙이 다양한 종류의 데이터 저장소에 대해 알지 않기를 원한다.

 

[클린 아키텍처?]

분명하게 이 예제의 맥락이라면 클린 아키텍처 접근법을 적용해서 유스케이스, 경계, 엔티티, 그리고 관련된 데이터 구조를 모두 만드는 일도 쉬운 일이다.

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

 

[흐름 횡단하기]

네트워크(Network) 컴포넌트 추가. 이 구성은 데이터 흐름을 세 개의 흐름으로 분리하며, 이들 흐름은 모두 GameRules가 제어한다.

[흐름 분리하기]

대규모의 플레이어가 동시에 플레이할 수 있는 버전. MoveManagement는 플레이어의 컴퓨터에서 직접 처리되지만 PlayerManagement는 서버에서 처리된다.

 

[결론]

아키텍처 경계가 어디에나 존재한다는 사실을 보여주기 위함이다. 아키텍트로서 우리는 아키텍처 경계가 언제 필요한지를 신중하게 파악해내야 한다. 또한 우리는 이러한 경계를 제대로 구현하려면 비용이 많이 든다는 사실도 인지하고 있어야 한다. 이와 동시에 이러한 경계가 무시되었다면 나중에 다시 추가하는 비용이 크다는 사실도 알아야 한다.

한편으로는 매우 똑똑한 일부 사람들이 우리에게 수년 동안 말해왔듯이, 추상화가 필요하리라고 미리 예측해서는 안 된다. 이것이 바로 YAGNI가 말하는 철학이다. 이 문구에는 지혜가 담겨 있는데, 오버 엔지니어링이 언더 엔지니어링보다 나쁠 때가 훨씬 많기 때문이다.

오! 소프트웨어 아키텍트여, 당신은 미래를 내다봐야만 한다. 당신은 현명하게 추측해야만 한다. 당신은 비용을 산정하고 어디에 아키텍처 경계를 둬야 할지, 그리고 완벽하게 구현할 경계는 무엇인지와 부분적으로 구현할 경계와 무시할 경계는 무엇인지를 결정해야만 한다.

우리의 목표는 경계의 구현 비용이 그걸 무시해서 생기는 비용보다 적어지는 바로 그 변곡점에서 경계를 구현하는 것이다.