[Clean Architecture 정리] 25장. 계층과 경계

25장. 계층과 경계

 

사냥 게임

어떤 간단한 게임을 만들 때, 1) 다국어 UI를 제공하고 2) 게임 진행 상태를 변경 될 수 있는 저장소에 저장 한다고 가정하자.

 

위의 형태로 컴포넌트를 분리하고 의존성을 관리하면 어떤 언어에 대한 요구가 있더라도 업무 규칙(Game Rule)을 재사용 가능하고, 저장소의 변경이 업무 규칙에 영향을 주지 않는다.

 

 

 

클린 아키텍처 ?

소프트웨어 시스템이 성장함에 따라서 변경은 계속해서 발생하게 되고, 변경의 축에 의해 정의되는 아키텍처 경계는 잠재되어 있다.

사용자로부터 텍스트를 입력받는 매커니즘이 변경될 수 있다면, 위와 같이 Text Delivery라는 API역할을 하는 추상 컴포넌트를 생성할 수 있다. 이 때, API는 구현하는 쪽이 아닌 사용하는 쪽에서 정의한다.

 

위의 추상 컴포넌트의 경우 다형적 Boudary 인터페이스이며, 인터페이스가 정의하는 API는 의존성 흐름의 상위에 위치한 컴포넌트에 속한다. 실제 구체 컴포넌트의 서비스는 추상 API 컴포넌트가 정의하는 다형적 인터페이스를 통해 제공된다. 

 

또한, 위 구성은 데이터 흐름을 1) 통신과 2) 영속성으로 효과적으로 분리하고 최종 처리는 두 흐름이 모두 거치게 되는 Game Rule 컴포넌트가 된다.

 

 

흐름 횡단하고 분리하기

 

데이터 흐름은 하나 이상일 수 있다.

예제의 간단한 게임을 네트워크에서 실행할 수 있다고 했을 때, 이전의 설계 방식으로는 Game Rule에서 모든 데이터 흐름을 처리하게 되고, 데이터의 흐름이 많아질수록 Game Rule이 처리해야하는 역할을 많아지게 된다.

 

위의 구성처럼 업무 규칙을 저수준(Move Management), 고수준(Player Management)으로 세분화하면 하나의 컴포넌트에서 처리해야할 데이터 흐름을 줄일 수 있다.

 

또한, 업무 규칙을 저수준, 고수준으로 분리하는 API를 둠으로써, 저수준 정책은 PC와 같은 클라이언트에서 처리하고 고수준 정책은 서버에서 처리해 마이크로서비스 API 형태로 제공해 완벽한 형태의 아키텍처 경계를 만들 수 있다.

 

 

결론

아키텍처 경계는 어디에나 존재할 수 있다. 하지만, 경계를 만드는 비용은 크기 때문에 언제 어디에 경계가 필요하고 만들 것에 대해서는 신중하게 판단해야 한다.

 

YAGNI(You Aren't Going to Need it)에서 말하는 철학에 따르면, 오버 엔지니어링이 언더 엔지니어링보다 나쁠 때가 훨씬 많다.

 

경계는 만드는 때는 경계의 구현 비용이 그것을 무시했을 때 생기는 비용보다 적어지는 변곡점이다.

 

 

서적 : http://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24