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

[23장] 프레젠터와 험블 객체

프레젠터는 험블 객체(Humble Object, 대강 만든 객체) 패턴을 따른 형태로, 아키텍처 경계를 식별하고 보호하는 데 도움이 ㅗ딘다.

 

[험블 객체 패턴]

험블 객체 패턴은 디자인 패턴으로, 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안되었다. 행위들을 두 개의 모듈 또는 클래스로 나눈다. 이들 모듈 중 하나가 험블(humble)이다. 가장 기본적인 본질은 남기고, 테스트하기 어려운 행위를 모두 험블 객체로 옮긴다. 험블 객체 패턴을 사용하면 두 부류의 행위를 분리하여 프레젠터와 뷰라는 서로 다른 클래스로 만들 수 있다.

 

[프레젠터와 뷰]

뷰는 험블 객체이고 테스트하기 어렵다. 뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하지는 않는다. 프레젠터는 테스트하기 쉬운 객체다. 프레젠터의 역할은 애플리케이션으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 것이다.

프레젠터는 적절한 형식의 문자열이 테이블 형태를 가지도록 뷰 모델에 로드한다. 화면에 표시되고 애플리케이션에서 어느 정도 제어할 수 잇는 요소라면 무조건 뷰 모델 내부에 문자열, 불(boolean), 또는 열거형(enum) 형태로 표현한다. 뷰는 뷰 모델의 데이터를 화면으로 로드할 뿐이며, 이 외에 뷰가 맡은 역할은 전혀 없다.

 

[테스트와 아키텍처]

험블 객체 패턴 - 행위를 테스트하기 쉬운 부분과 테스트하기 어려운 부분으로 분리하면 아키텍처 경계가 정의됨. 프레젠터와 뷰 사이의 경계는 이러한 경계중 하나.

 

[데이터베이스 게이트웨이]

유스케이스 인터랙터와 데이터베이스 사이에는 데이터베이스 게이트웨이가 위치한다. 이 게이트웨이는 다형적 ㅇ니터페이스로, 애플리케이션이 데이터베이스에 수행하는 생성, 조회, 갱신, 삭제 작업과 관련된 모든 메서드를 포함한다.

유스케이스 계층은 필요한 메서드를 제공하는 게이트웨이 인터페이스를 호추한다. 그리고 인터페이스의 구현체는 데이터베이스 계층에 위치한다. 이 구현체는 험블 객체다. 이와 달리 인터랙터는 애플리케이션에 특화된 업무 규칙을 캡슐화하기 때문에 험블 객체가 아니다.

 

[데이터 매퍼]

데이터는 모두 private으로 선언되므로 객체의 사용자는 데이터를 볼 수 없다. 사용자는 객체에서 public 메서드만 볼 수 있다. 따라서 사용자 관점에서 볼 때 객체는 단순히 오퍼레이션의 집합이다.

 

[서비스 리스너]

서비스 리스너(service listener)가 서비스 인터페이스로부터 데이터를 수신하고, 데이터를 애플리케이션에서 사용할 수 있게 간단한 데이터 구조로 포맷을 변경한다. 그런 후 이 데이터 구조는 서비스 경계를 가로질러서 내부로 전달된다.

 

[결론]

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