Component Refactoring [4]

구현 컴포넌트 분석 - 컴포넌트 Dependency 파악

컴포넌트 Dependency는 현재 구현된 컴포넌트의 의존관계에서 원칙에 위배되는 내용을 파악하는 단계이다. 이 단계에서는 이러한 의존관계의 위배 현상의 피상적인 결과 뿐만 아니라, 왜 그와 같은 의존관계가 형성될 수 밖에 없는지의 원인까지도 가능한 파악되어야 한다.
이러한 컴포넌트 의존관계 원칙은 컴포넌트 설계 전에 우선 결정이 되어야 하며, 설계를 진행하고 구현하는 과정에서 이러한 피드백을 받아서 다시 의존관계를 조정해야 한다.

유형
의존관계가 위배되는 유형은 아래와 같이 크게 세가지 형태로 나뉠 수 있다.

- Dependency 의 역전 현상 (엔티티에서 프로세스로의 호출, 유틸리티에서 프로세스 혹은 엔티티로의 호출) [1]
- Dependency Cycling 현상 [2]
- 인터페이스간 호출이 아닌 컴포넌트 내부 객체에 대한 호출로 인한 Dependency 현상 [3]

분석 방법

- 원칙에 위배되는 컴포넌트를 우선 분석
- 컴포넌트간 인터페이스 호출이 잦은 컴포넌트 분석
- 해당 컴포넌트를 타부문에서 사용하는 경우에 대한 분석
- 타 컴포넌트에서 인터페이스 정보 모델이 사용되는 컴포넌트에 대해서 분석
- 해당 컴포넌트의 인터페이스를 사용하는 모든 아키텍처 요소 점검 (배치, 채널 등)

오른쪽 그림에서 컴포넌트의 의존관계가 역전이 생기는 현상에서 ①은 원칙에 대해 위배하는 경우이며, ②는 의존관계가 순환이 된느 경우이다. 2개의 컴포넌트 양쪽에서만이 아니라, 세개 이상의 경우에도 순환관계가 발생할 수 있는데, 이 경우 그 현상을 파악하기가 쉽지 않다. (이러한 경우에는 의존관계를 파악하는 도구에 도움을 받는 것이 좋다.) ③은 인터페이스 호출이 아닌, 컴포넌트 내부 객체 혹은 정보모델로의 의존관계가 발생하는 경우이다. 이와 같은 경우, 해당 객체를 두개의 컴포넌트에서 별도로 분리하는 방안도 고려할 수 있다. (아니면, 최소한 공통되는 인터페이스를 별도로 분리하던지 해야 한다.)