컴포넌트 클러스터링 [4]

3.4 역할
클러스터링의 대상이 되는 객체/컴포넌트의 역할에 따른 클러스터링이 가능하다. 따라서 임의의 객체/컴포넌트는 예를 들면, Controller의 역할을 수행하기 위해 클러스터를 형성한다. 다음 그림은 컴포넌트를 위한  여섯 가지 역할을 제시한다. 이 역시 컴포넌트 클러스터링을 위한 또 하나의 기준이 될 수 있다. 컴포넌트 클러스터링 목표 도메인의 특성에 따라 새로운 역할이 존재할 수 있으며, 시스템에 새로운 역할의 추가 및 기존 역할의 확장을 할 수 있다. 역할을 클러스터링에 사용하는 방식은 RDD (Responsibility Driven Design) 기반의 OOAD 기법에서 가져온 개념으로 일부는 비즈니스 컴포넌트를 구성하는 내부의 소규모 컴포넌트들에 역할과 책임을 부여할 때 사용할 수 있다. 

그림 3-5. 역할에 의한 컴포넌트 클러스터링

Service Provider
특수한 기능이나  연산기능이 필요로 하는 책임성은 Service Provider 역할로 할당된다. Service Provider 역할을 하는 객체가 여러 개라 할지라도, 각각의 객체는 나름대로 특수한 작업을 수행하도록 역할이 할당되어 있다.
Service Provider의 역할에 대해서 다음과 같은 부분을 점검해야 한다.

• Service Provider가 사용하는 정보는 어떠한 객체가 가지고 있는가? Service Provider가 받기만 하면 되는가 아니면 요청을 해야하는가?
• 서비스는 설정가능한가? 설정 정보는 어떠한 객체가 가지고 있는가? 어떻게 서비스가 설정될 것인가?
• Service Provider가 담당하는 어떠한 역할이 변경될 경향이 있는가? 어플리케이션이 성숙할 때마다 진화하는가? 한 객체에 포함되어 있는 책임성을 제거하기 위해서 해당 Service Provider를 분리해야 하는가?
• 어플리케이션은 동일한 서비스의 서로 다른 형태를 요구하는가? 어떻게 서비스를 다양화하고, 그 각각의 서비스를 누가 담당할 것인가?

Information Holder
Information Holder는 어떠한 사실을 알고 있다는 것이 주요한 책임성이다. 일반적으로 다른 객체와 정보를 알기 위해서 요청하는 경우를 제외하고는 상호작용을 그렇게 많이 하지 않는다. 정보를 요청한 후에 더 이상 다시 요청할 필요가 없다. 때로는 정보를 수집하는 것조차도 다른 객체를 통해서 할 수도 있다. Information Holder는 전체적으로 생성될 수 있으며, 알아야 할 것들을 포함할 수 있다. Information Holder의 역할을 이러한 정보를 담고 있고 일관성을 유지하는 것이다.

Interfacer
Interfacer는 기본적으로 서로 분리된 부분을 연결해주는 다리(bridge) 역할을 제공한다. 사용자와 소프트웨어 간 (사용자 인터페이스), 인접한 다른 객체들 간 (내부 인터페이스), 개발된 어플리케이션과 외부의 서비스나 프로그램 간 (외부 인터페이스) 다리 역할을 제공한다. Interfacer의 각각의 형태는 그 자체의 협업 구조(collaboration profile)를 가지고 있다.

Controller
Controller는 자신이 결정하고 다른 객체에게 행위를 지시한다. Controller는 결정하기 위해서 정보를 수집하거나 다른 객체에게 행위를 지시하기 위해서 상호작용하게 된다. 일반적으로 결정을 위해서 역할을 수행하는 것이지 또 다른 하위 행위를 수행하기 위함이 아니다. 행위를 달성하기 위한 책임성을 종종 다른 객체에게 위임하기도 하는데, Controller가 관리하는 더 큰 업무를 수행하는 특수한 책임성을 그 객체에게 부여한다. Controller와 Coordinator의 차이는 정도 차이인데, Controller는 해결하고 조치를 취하지만, Coordinator는 어떤 일을 할지 지시하고 결정은 극히 드물게 하게 된다.

Coordinator
Coordinator는 다른 객체에게 정보를 전달하고 행위를 지시하기 위해서 존재한다. 객체 간의 연결을 유지하고 정보를 전달하고 요청하는데 초점을 맞추고 있다. Coordinator의 역할은 다른 객체들의 의사소통과 작업을 원활하게 한다. Structurer와 같이, 다른 객체와 연결을 유지하지만, 그 목적은 약간 상이하다. Coordinator는 작업 객체들의 행위를 관리하는데 중점을 두지만, Structurer는 객체들을 묶는데 관리하고 응집성이 있는 관점을 제공한다.

Structurer
대부분의 어플리케이션은 정보를 구조화하고 서로 다른 방식으로 객체를 그룹핑한다. 객체는 풀링되고, 관리되고, 수집될 필요가 있다. 구조화하고 조직화할 책임을 가지는 객체는 어디에선가 구조화시키는 것들을 얻어야 한다. Structurer가 구조화하는 객체들은 DB 연결을 하거나 소프트웨어 외부의 디바이스와 연결하는 역할을 담당하기도 한다. 이러한 객체들의 협업을 살펴보면 구조화된 객체들이 만들어지거나 어플리케이션이 실행하는 동안에 Structurer 에 추가된다. 구조화된 정보를 조회하고, 비교하고 수정하는 책임성에서도 이러한 협업을 볼 수 있다.