Portfolio

경계를 완벽하게 만드는 데는 비용이 많이 든다.

많은 경우에, 뛰어난 아키텍트라면 이러한 경계를 만드는 비용이 너무 크다고 판단하면서도, 한편으로는 나중에 필요할 수 도 있으므로 이러한 경계에 필요한 공간을 확보하기 원할 수 도 있다.

이를 부분적 경계로 구현해볼 수 있다.

독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행하되, 단일 컴포넌트 즉, 모노리틱한 구조로 그대로 두는 것이다.

부분적 경계를 만들려면 완벽한 경계를 만들때 만큼의 코드량과 사전 설계가 필요하지만 다수의 컴포넌트를 관리하는 배포 관점이나 추적을 할 필요가 없다.

하지만 FitNesse 이야기를 본다면 이 접근법가 위험할 수 있다고 한다.

Client를 ServiceImpl로 부터 격리시키는 데 필요한 의존성 역전을 적용하였다. ( 전통적인 전략 패턴 ) → DIP가 아닌가…?

하지만 점섬 화살표에서 보듯이 비밀 통로가 생기는 일을 막을 방법이 없다.

→ 어떤 비밀 통로를 의미하는 걸까? 쌍방향 인터페이스는 Mapper 클래스와 동일한 의미라면 client에 있어야 하는 Dto를 ServiceImpl이 의존하는 것이 비밀 통로일까?

훨씬 더 단순한 경계는 퍼사드 패턴이며 의존성 역전까지 희생하게 된다.

경계의 경우 퍼사드 클래스로만 간단히 정의된다.

퍼사드 클래스에는 모든 서비스 클래스를 메서드 형태로 정의하고, 서비스 호출이 발생하면 해당 서비스 클래스로 호출을 전달한다.

퍼사드 클래스가 여러 서비스를 의존하게 되는 것이다.

위의 세 전략은 각 나름의 비용과 장점을 지닌다. 고로, 각 접근법은 해당 경계가 실제로 구체화될 때 적절하게 사용하는 것이 좋아보인다.

24장 부분적 경계