소프트웨어는 정책을 기술한 것이며 프로그램의 핵심은 정책이다. 하지만 거대한 정책을 하나로 냅두지 않고 조그만 정책으로 쪼갤 수 있다. (포멧 정의, 데이터 검증 정책 등) 소프트웨어 아키텍처를 개발하고 기술할때에는 이런 정책의 분리가 매우 신중히 있어야 하며 동일한 이유로 동일한 시점에 변경되는 정책은 동일한 수준, 동일한 컴포넌트에 위치 해야한다.
컴포넌트를 그래프로 표현을 많이 하는데 정점은 동일한 수준의 정책을 포함하는 컴포넌트이며 방향이 있는 간선은 컴포넌트 사이의 의존성을 나타낸다. (의존성은 컴파일 타임 의존성을 의미한다. 자바의 경우 import, C#에서는 using 구문)
앞서서 계속 살펴봤다시피 저수준 컴포넌트가 고수준 컴포넌트에 의존하도록 설계되어야 한다.
수준을 엄밀하게 정의하자면 입력과 출력까지의 거리이다.
입력과 출력으로부터 멀어질수록 고수준의 정책이다.
입력과 출력이 번역에 의존하고 있으며 번역 컴포넌트는 최고 수준 컴포넌트이다.
주의 : 데이터의 흐름과 컴포넌트의 의존성 간의 관계는 반드시 일치하지 않는다.
주의 점에서 알 수 있다시피 데이터 흐름과는 무관하게 수준에 따라서 의존성의 방향이 결정되어야 한다.
다음 클래스 다이어그램을 살펴보자.
여기서 Console Reader와 Console Writer가 입출력이다. 이 구조를 확인해보면 입출력을 고수준이며 가장 핵심 정책인 Encrypt에서 분리 시킴을 알 수 있다. 이러한 구조를 통해서 입출력 구조가 바뀌더라도 고수준 정책은 거의 영향을 받지 않을 수 있다.
정책을 컴포넌트로 묶는 기준은 정책이 변경되는 것에 따라 달리는데, 단일 책임 원칙과 공통 폐쇄 원칙에 따르면 동일한 이유로 동일한 시점에 변경되는 정책은 함께 묶인다. 그러다보니 분리를 시켜놓으면 저수준이 자주 중요하지 않은 이유로 변경되는 것과 분리가 가능 하며 영향도를 줄일 수 있다.
따라서 더 확장 시키자면 저수준 컴포넌트가 고수준 컴포넌트에 플러그인 되야한다로 볼 수 있다.