- 아키텍처 경계를 완벽하게 만드는 데는 비용이 많이 듦
- 쌍방향의 다형적 Boundary 인터페이스
- Input, Output 을 위한 데이터 구조
- 두 영역을 독립적으로 컴파일하고 배포할 수 있는 컴포넌트로 격리하는 데 필요한 모든 의존성 관리해야 함
- 많은 경우에, 뛰어난 아키텍트라면 이러한 경계를 만드는 비용이 너무 크다고 판단하면서도, 한편으로는 나중에 필요할 수도 있으므로 이러한 경계에 필요한 공간을 확보하기 원할 수도 있음
- 애자일의 YAGNI 원칙에 위배되지만, 어쩌면 필요할 수 도 있겠다는 생각에 부분적 경계 partial boundary 를 구현해볼 수 있음
- You Aren’t Going to Need It
- 부분적 경계 partial boundary 를 생성하는 방법 하나
- 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후 단일 컴포넌트에 그대로 모아만 두는 것
- 쌍방향 인터페이스, 입출력 데이터 구조 등 모든 것이 완전히 준비되어 있지만, 이 모두를 단일 컴포넌트로 컴파일해서 배포함
- 이처럼 부분적 경계를 만들려면 완벽한 경계를 만들 때 만큼의 코드량과 사전 설계가 필요하지만, 다수의 컴포넌트를 관리하는 작업은 하지 않아도 됨
- 추적을 위한 버전 번호도 없음
- 배포 관리 부담도 없음
- 이 차이는 가볍지 않음
- 완벽한 형태의 아키텍처 경계는 양방향으로 격리된 상태를 유지해야 하므로, 쌍방향 Boundary 인터페이스를 사용함
- 양방향으로 격리된 상태를 유지하려면 초기 설정할 때나 지속적으로 유지할 때도 비용이 많이 듦
- 추후 완벽한 형태의 경계로 확장할 수 있는 공간을 확보하고자 할 때 전략 패턴을 사용하면 됨
- 이 방식이 미래에 필요할 아키텍처 경계를 위한 무대를 마련한다는 점은 명백함
- 또한 이러한 분리는 매우 빠르게 붕괴될 수 있다는 점 역시 분명함
- 점선과 같은 비밀 통로가 생기는 일을 막아야 함
- 일차원 경계보다 훨씬 더 단순한 경계는 퍼사드 Facade 패턴
- 이 경우에는 의존성 역전까지도 희생함
- 경계는 Facade 클래스로만 간단히 정의됨
- Facade 클래스에는 모든 서비스 클래스를 메서드 형태로 정의
- 서비스 호출이 발생하면 해당 서비스 클래스로 호출을 전달함
- 클라이언트는 이들 서비스 클래스에 직접 접근할 수 없음
- 하지만 Client 가 이 모든 서비스 클래스에 대해 추이 종속성을 가지게 된 것을 주목
- 만약 정적 언어였다면, 서비스 클래스 중 하나에서 소스 코드가 변경되면 Client 도 무조건 재컴파일 필요
- 이러한 구조라면 비밀 통로 또한 정말 쉽게 만들 수 있다는 사실도 충분히 파악 가능
- 아키텍처 경계를 부분적으로 구현하는 간단한 방법 세 가지
- 물론 이 외에도 방법은 많음
- 이러한 접근법 각각은 나름의 비용과 장점을 지님
- 각 접근법은 완벽한 형태의 경계를 담기 위한 공간으로써, 적절하게 사용할 수 있는 상황이 서로 다름
- 또한 각 접근법은 해당 경계가 실제로 구체화되지 않으면 가치가 떨어질 수 있음
- 아키텍처 경계가 언제, 어디에 존재해야 할지, 그리고 그 경계를 완벽하게 구현할지 아니면 부분적으로 구현할지를 결정하는 일 또한 아키텍트의 역할