[Architecture] 5부 아키텍처 : 24장 부분적 경계

 

 

#클린아키텍처 #cleanArchitecture #부분적경계 #전략패턴 #퍼사드패턴

​

​

​

24장에서는,

앞 장에서 계속 설명한 컴포넌트 간 경계를 긋는 일을

완벽하게 구현하기 위해서는 현실적으로 비용이 많이 든다는 점에 대해서

"부분적 경계"를 만들 수 있는 현실적인 타협안들을 제시한다.

​

​

완벽한 아키텍처를 만들기 위해서는

쌍방향의 다형적 Boundary 인터페이스,

Input과 Output을 위한 데이터 구조를 만들어야 할 뿐 아니라,

두 영역을 독립적으로 컴파일하고 배포할 수 있는 컴포넌트로

격리하는 데 필요한 모든 의존성을 관리해야 한다.

​

이렇게 하기 위해선

엄청난 노력을 기울여야 하고 유지하는 데도 많은 노력이 수반된다.

​

​

​

마지막 단계 건너뛰기

​

부분적 경계를 생성하는 방법 중 하나는

독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은

모두 수행한 후,

​

단일 컴포넌트에 그대로 모아만 두는 것이다.

​

쌍향방 인터페이스로 한 컴포넌트에 있고,

입출력 데이터 구조로 한 컴포넌트 안에 있으며

모든 것이 추후 컴포넌트를 분리하기 위한 작업이 준비되어 있다.

​

하지만 이 모두를 단일 컴포넌트로 컴파일하여 배포한다.

​

이렇게 하면 장점이,

다수의 컴포넌트를 관리하는 작업은 하지 않아도 되며,

추적을 위한 버전 번호도 필요 없고

배포 관리 부담도 없으니 현실적인 타협안이 될 수 있다.

​

​

사용자가 하나의 jar 파일을 다운로드 하면,

의존성이 있는 또다른 jar 파일을 찾아다니거나

버전 호환성을 해결하는 등의 번거로운 작업을 하지 않고도

실행할 수 있게 만들 수 있다.

​

​

​

​

​

​

​

일차원 경계

완벽한 형태의 아키텍처 경계는 양방향으로 격리된 상태를 유지해야 하므로

쌍방향 Boundary 인터페이스를 사용한다.

양방향으로 격리된 상태를 유지하려면

초기 설정할 때나 지속적으로 유지할 때도 비용이 많이 든다.

​

추후 완벽한 형태의 경계로 확장할 수 있는 공간을 확보하고자 할 때

우리는 전통적인 "전략 패턴" (Strategy Pattern)을 사용할 수 있다.

​

ServiceBoundary 인터페이스는 클라이언트가 사용하며

ServiceImpl 클래스가 구현한다.

​

​

이 전략 패턴은 미래에 필요할 아키텍처 경계를 위한 바탕을 마련한다.

Client를 ServiceImpl 구체 클랫그로부터 격리시키는 데 필요한

의존성 역전이 적용되었기 때문이다.

​

​

​

​

​

​

​

퍼사드 패턴

이보다 훨씬 더 단순한 경계는 퍼사드 패턴을 예시로 들 수 있다.

퍼사드 패턴은 의존성 역전까지도 희생하며,

컴포넌트 경계는 Facade 클래스로만 간단히 정의된다.

​

​

​

​

Facade 클래스에는 모든 서비스 클래스를

메서드 형태로 정의하고,

서비스 호출이 발생하면,

해당 서비스 클래스로 호출만 전달하는 단순 전달용 메서드만 정의되어있을 뿐이다.

클라이언트는 대신 다른 서비스 클래스에 직접 접근할 수 없으며,

이 Facade 클래스를 통해서만 간접적으로 다른 서비스 클래스의 메서드를 호출할 수 있다.

​

​

​

하지만, Client가 모든 서비스 클래스에 대해

추이 종속성을 가지게 된 것에 주목하다.

서비스 클래스 중 하나에서 소스 코드의 변경이 발생하면,

Client의 코드도 무조건 재컴파일해야 할 것이다.

​

​

​

​

​

​

​

​

결론

앞서 설명한 세가지 방법은 아키텍처 경계를 부분적으로 구현하는 방법 중

일부분일 뿐이다. 이 외에도 방법은 다양하다.

​

​

이들 방법은 각각 나름의 비용과 장점을 지닌다.

각 접근법은 완벽한 형태의 경계를 담기 위한 공간으로써,

적절하게 사용할 수 있는 상황이 서로 다르다.

​

또한 각 접근법은 해당 경계가 실제로 구체화되지 않으면

가치가 떨어질 수 있다.

​

​

아키텍처 경계가 언제, 어디에 존재해야 할지,

그리고 그 경계를 완벽하게 구현할지

아니면 부분적으고 구현할지 결정하는 일 또한

아키텍트의 역할이다.