[Clean Architecture 정리] 22장. 클린 아키텍처

험블 객체 패턴

테스트하기 어려운 행위와 테스트하기 쉬운 행위를 분리하기 쉽게 하는 목적으로 고안
행위를 두개의 모듈이나 클래스로 나눈다. 이들 모듈 중 하나가 험블이다.
가장 기본적인 본질은 남기고, 테스트 하기 어려운 행위를 모두 험블 객체로 옮긴다.

GUI의 경우 화면을 보며 요소들이 필요한 위치에 표시되었는지 단위 테스트가 어려움.
하지만 GUI에서 수행되는 행위는 쉽게 테스트가능.
이 부류의 행위를 험블 객체 패턴을 사용하면 프레젠터와 뷰로 나눌 수 있음.

프레젠터와 뷰

뷰는 험블객체이고 테스트하기 어렵다.
뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하지 않는다.

프레젠터는 테스트하기 쉬운 객체다.
프레젠터의 역할은 애플리케이션(server)으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 것이다.
따라서 뷰는 데이터를 화면으로 전달하기만 하면 된다.

테스트와 아키텍처

좋은 아키텍처는 테스트하기 용이해야 한다.
험블 객체 패턴이 좋은 예이며, 테스트하는 행위를 어렵거나 쉬운것으로 분리하면 아키텍처 경계가 정의 되기 때문.

데이터베이스 게이트웨이

유스케이스 인터랙터와 데이터베이스 사이에는
데이터베이스 게이트웨이(다형적 인터페이스이며 CRUD 메서드를 포함)가 위치함.
유스케이스 계층은 SQL을 허용하지 않기 때문에 게이트웨이 인터페이스를 호출하며 이 인터페이스의 구현체는 데이터베이스 계층에 존재함.
이 구현체는 험블 객체임. → 직접 SQL사용함.
이와 달리 인터랙터는 험블 객체가 아님. → 애플리케이션에 특화된 업무 규칙을 캡슐화 함.
테스트하기 쉽다.

게이트웨이는 스텁(stub), 모의(mock)나 테스트 더블(test-double)로 적당히 교체할 수 있기 때문이다.

데이터 매퍼

하이버네이트 같은 ORM(Object Relational Mapping)은 어느 계층인가?

객체 관계 매퍼(Object Relational Mapper, ORM) 같은 건 존재하지 않는다고 한다.
사용자 입장에서 볼 때 단순히 오퍼레이션의 집합이다.
객체와 달리 데이터 구조는 함축된 행위를 가지지 않는 public 데이터 변수의 집합이다.

이러한 ORM 시스템은 어디에 위치해야 하는가?
데이터베이스 계층이다.
ORM은 게이트웨이 인터페이스와 데이터베이스 사이에서 일종의 또 다른 험블 객체 경계를 형성한다.

서비스 리스너

애플리케이션이 다른 서비스(server)와 통신해야 하거나 일련의 서비스를 제공해야 한다면,

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

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

결론

각 아키텍처 경계마다 경계 가까이 숨어 있는 험블 객체 패턴을 발견할 수 있다.
경계를 넘나드는 통신은 거의 다 간단한 데이터 구조를 수반할 때가 많고 그 경계는 테스트하기 어려운 무언가와 쉬운 무언가로 분리된다.
이렇게 아키텍처 경계에서 험블 객체 패턴을 사용하면 전체 시스템의 테스트 용이성을 크게 향상시킬 수 있다.