24장 부분적 경계

 

들어가며

 

아키텍처를 완벽히 만드는 데는 당연히 비용이 많이 듦.

애자일 커뮤니티에 속한 사람 중 많은 이는 선행적인 아키텍처 설계를 탐탁치 않게 여김.

하지만 아키텍트는 "어쩌면 필요할지도." 라는 생각이 들 수 도 있기 때문에 만약 그렇다면 부분적 경계를 구현해볼 수 있음.

 

 

 

마지막 단계를 건너뛰기

 

부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 두는 것임.

 

부분적 경계 전략을 기반으로 FitNess는 웹 서버 컴포넌트가 위키나 테스트 영역과는 분리되도록 설계했음. 새로운 웹 기반 애플리케이션을 만들 때 해당 웹 컴포넌트를 재사용할 수도 있다고 생각했기 때문. 그러나 시간이 흐르며, 별도로 분리한 웹 컴포넌트가 재사용 될 가능성은 전혀 없을 것임이 명백 해짐.

 

웹 컴포넌트와 위키 컴포넌트 사이의 구분도 약화되기 시작함.

 

 

 

일차원 경계

 

완벽한 아키텍처 경계는 양방향으로 격리된 상태를 유지해야하므로 쌍방향 Boundary 인터페이스를 사용함.

그러나 비용이 너무 많이듦.

 

 

그림은 전통적인 전략 패턴임.

 

Client는 Service Boundary를 사용하며 이는 ServiceImpl가 구현함.

Client를 ServiceImpl로 부터 격리 시키고자 의존성 역전 원칙을 적용함.

그러나 쌍방향 인터페이스가 없고 개발자와 아키텍트가 제대로 훈련되어 있지 않다면, 전략 패턴은 위에 점선과 같은 비밀 통로가 생길 수 있음.

 

 

 

퍼사드

 

퍼사드 패턴

 

훨씬 더 간단한 경계로써 모든 서비스 클래스를 메서드 형태로 정의하고 있는 Facade 클래스가 있음.

클라이언트는 서비스 클래스를 직접 접근할 수 없음.

그러나 정적 언어일 경우 클라이언트가 모든 서비스 클래스에 대해 추이 종속성 가짐

→ 서비스 클래스 하나가 변경되면 클라이언트도 무조건 재 컴파일 해야함.