부분적 경계

• 아키텍처 경계를 완벽하게 만들기 위해선 많은 비용이 든다.
  • 쌍방향의 다형적 Boundary 인터페이스, Input과 Output을 위한 데이터 구조 생성, 두 영역을 독립적으로 컴파일하고 배포할 수 있는 컴포넌트로 격리하는 데 필요한 모든 의존성 관리르 해야 하기 때문.
• 처음부터 완벽한 경계를 나누지 않고 부분적 경계를 구현해보는 방법은 없을까.

마지막 단계를 건너뛰기

• 부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 두는 것이다.
• 이러한 전략을 토대로 FitNesse의 웹 서버 컴포넌트는 FitNesse의 위키나 테스트 영역과는 분리되도록 설계되었다. 그러나 시간이 흐르면서 별도로 분리한 웹 컴포넌트가 재사용될 가능성은 없어지고, 웹 컴포넌트와 위키 컴포넌트 사이의 구분도 약화되기 시작했다.

일차원 경계

이미지 출처 : https://hwannny.tistory.com/43

• 완벽한 형태의 아키테처 경계는 양방향으로 격리된 상태를 유지해야 하므로 쌍방향 Boundary 인터페이스를 사용한다. 그러나 비용이 많이 든다.
• 위 그림은 전통적인 전략 패턴을 사용한 사례로써, 추후 완벽한 형태의 경계로 확장할 수 있는 공간을 확보하고자 할 대 사용할 수 있는 구조이다.
• ServiceBoundary 인터페이스는 Client가 사용하며, ServiceImpl 클래스가 구현한다.
• 그러나 쌍방향 인터페이스가 없기 대문에 ServiceImpl와 Client 사이의 비밀통로가 생기는 일을 막을 수는 없다.

퍼사드

• 일차원 경계보다 훨씬 단순한 경계를 만들지만 의존성 역전을 희생하였다.
• 경계는 Facade 클래스로만 간단히 정의된다.
  • Facade 클래스에는 모든 서비스 클래스를 메서드 형태롤 정의하고, 서비스 호출이 발생하면 해당 서비스 클래스로 호출을 전달한다.
  • 클라이언트는 이들 서비스 클래스에 직접 접근할 수 없다.
• 하지만 Client는 이 모든 Service 클래스에 대해 추이 종속성을 가지게 된다.
  • 서비스 클래스 중 하나에서 소스 코드가 변경되면 Client도 무조건 재컴파일해야 한다.
  • 비밀통로 또한 쉽게 생길 수 있다.