• 뛰어난 아키텍트라면 경계를 만드는 비용이 너무 크다고 판단해도, 필요한 공간을 확보하기 원할 수도 있다
• 이럴 때 부분적 경계 적용

마지막 단계를 건너뛰기

• 부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 두는 것
• 완벽한 경계를 만들 때 만큼의 코드량과 사전 설계가 필요하지만, 다수의 컴포넌트 관리할 필요 X
• 이는 FitNesse를 뒷받침했던 초기 전략. 웹 서버 컴포넌트는 위키나 테스트 영역과는 분리하도록 설계
• 하지만 시간이 흐르면서 별도로 분리한 웹 컴포넌트가 재사용될 가능성이 적어지고 웹과 위키 컴포넌트 사이의 구분이 약화되는 위험 발생

일차원 경계

• 완벽한 형태의 아키텍처 경계는 양방향으로 격리된 상태를 유지해야 하므로 쌍방향 Bounary 인터페이스 사용
• 그림 24.1 추후 완벽한 형태의 경계로 확장할 수 있는 공간을 확보하고자 할 때 활용 가능한 더 간단한 전략 (Strategy) 패턴

퍼사드

• 훨씬 더 단순한 경계는 퍼사드 패턴으로, 심지어 의존성 역전까지도 희생
• Facade 클래스에는 모든 서비스 클래스를 메서드 형태로 정의하고, 서비스 호출이 발생하면 해당 서비스 클래스로 호출 전달
• 클라이언트는 이들 서비스 클래스에 직접 전달 X
• 그림 24.2 퍼사트(Facade) 패턴
• 하지만 Client가 이 모든 서비스 클래스에 대해 추이 족송성을 가지게 된다
• 정적 언어였다면 서비스 클래스 중 하나가 소스 코드가 변경되면 Client도 무조건 재컴파일
• 비밀 통로 또한 정말 쉽게 만들 수 있다는 사실도 존재

결론

• 앞서 말한 접근법 각각은 나름의 비용과 장점을 지닌다