[Clean Architecture] 22. 프레젠터와 험블객체

프레젠터는 험블 객체 패턴을 따른 형태로, 아키텍처 경계를 식별하고 보호하는 데 도움이 된다.

22장 '클린 아키텍처'는 험블 객체 구현체들로 가득 차 있다.

험블 객체 패턴

• 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 분리하기 쉽게
• 가장 기본적인 본질은 남기고, 테스트하기 어려운 객체를 험블 객체로 옮김.
• 나머지 모듈에는 험블 객체에 속하지 않는, 테스트하기 쉬운 행위를 모두 옮긴다.

GUI의 경우 단위 테스트가 어려움

• 화면을 보면서 각 요소가 필요한 위치에 적절히 표시 되었는지 검사하는 테스트는 작성하기 매우 어렵다.

하지만 GUI에서 수행하는 행위의 대다수는 쉽게 테스트할 수 있다.

• 험블 객체 패턴을 사용하면 두 부류의 행위를 분리해 프레젠터와 뷰 라는 서로 다른 클래스로 만들 수 있다.

 

프레젠터와 뷰

 

뷰는 험블 객체이고 테스트하기 어렵다. 가능한 코드를 간단하게 유지한다.

 

• 뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하진 않는다.

프레젠터는 테스트하기 쉬운 객체다.

 

• 프레젠터의 역할은 애플리케이션으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 것
• 이를 통해 뷰는 데이터를 화면으로 전달하는 간단한 일만 처리하도록 만듬

예를 들어 특정 부분에 날짜를 표시하고자 한다면

 

• 애플리케이션 -> Date 객체 -> 프레젠터
• 프레젠터가 Date객체를 적절한 포맷의 문자열로 변환
• View 모델이라고 부르는 간단한 구조에 담아서 뷰에 전달

뷰는 이 모델에서 찾기만 하면 됨, 뷰는 뮤 모델의 데이터를 화면으로 로드할 뿐, 아무 역할이 없다.

 

즉, 보잘것 없다(humble).

 

테스트와 아키텍처

테스트 용이성은 좋은 아키텍처가 지녀야 할 속성으로 오랫동안 알려져 왔다.

 

• 험블 객체 패턴이 좋은 예인데, 행위를 테스트하기 쉬운 부분과 어려운 부분으로 분리하면 아키텍처 경계가 정의되기 때문이다.
• 프레젠터와 뷰 사이의 경계는 이러한 경계중 하나이며, 수많은 경계가 존재한다.

 

데이터베이스 게이트웨이

 

유스케이스 인터랙터와 데이터베이스 사이에는 데이터베이스 게이트웨이가 위치한다.

 

다형적 인터페이스로 애플리케이션이 DB에서 수행하는 생성/조회/갱신/삭제 작업과 관련된 모든 메서드를 포함한다.

 

• 예를들어 어제 로그인한 모든 사용자의 성(last name)을 알 수 있어야 한다면, UsertGateway 인터페이스는 getLastNamesOfUsersWhoLoggedInAfter 라는 메서드를 제공할 것임

유스케이스 계층은 SQL을 허용하지 않는다.

 

• 필요한 메서드를 제공하는 게이트웨이 인터페이스를 호출한다.
• 그리고 인터페이스의 구현체는 데이터베이스 계층에 위치한다.

 

서비스 리스너

애플리케이션이 다른 서비스와 통신해야 한다면 또는 또는 애플리케이션에서 일련의 서비스를 제공해야 할 때..

 

• 이 경우에도 서비스 경계를 생성하는 험블 객체 패턴을 발견할 수 있다.
• 서비스 리스너가 서비스 인터페이스로부터 데이터를 수신하고, 데이터를 애플리케이션에서 사용할 수 있게 간단한 데이터 구조로 포맷을 변경한다.

그 후 이 데이터 구조는 서비스 경계를 가로질러서 내부로 전달된다.

 

결론

각 아키텍처 경계마다 경계 가까이 숨어 있는 험블 객체 패턴을 발견할 수 있을 것이다.

 

• 경계를 넘나드는 통신은 거의 모두 간단한 데이터 구조를 수반할 때가 많고
• 대게 그 경계는 테스트하기 어려운 무언가와 테스트하기 쉬운 무언가로 분리할 것이다.

아키텍처 경계에서 험블 객체 패턴을 사용하면 전체 시스템의 테스트 용이성을 크게 높일 수 있다.