부분적 경계

다음은 클린 아키텍처 24장을 정리한 내용

 

아키텍처 경계를 완벽하게 만드는 데는 비용이 많이 든다. 쌍방향 다형적 Boundary 인터페이스, Input과 Output 을 위한 데이터 구조를 만들어야 할 뿐 아니라, 두 영역을 컴파일하고 배포할 수 있는 컴포넌트로 격리하는 데 필요한 모든 의존성을 관리해야 함. 

아래의 예시에서도 2가지 인터페이스를 사용해서 구현했음

22장에 나오는 시스템 설계 예시

많은 경우에 아키텍트들은 비용이 너무 크니까, 어느 정도 타협을 하면서 설계함. 애자일 커뮤니티에서는 YAGNI(You aren't going to need it) 같은 원칙을 위배하기 때문에 선행 적인 설계를 선호하지 않지만, 아키텍트라면 한 번쯤 언젠가 필요할 상활을 고민하는 게 좋음. 그렇다면 부분적 경계를 구현해 볼 수 있음 여기서는 3가지를 제안함

마지막 단계를 건너뛰기

부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 두는 것임. 쌍방향 인터페이스도 그 컴포넌트에 있고, 입출력 데이터 구조도 같이 있으며 , 모든 것이 완전히 준비되어 있음. 하지만 이 모두를 단일 컴포넌트에 배포 하는거임. 이렇게 구현하는 것도 완벽한 경계를 만들 때만큼 코드량과 사전 설계가 필요하긴 함. 하지만 다수의 컴포넌트를 관리하는 작업은 하지 않아도 됨. 추적을 위한 버전 번호도 없고, 배포 관리 부담도 없음. 이 차이는 생각보다 큼.
하지만 이 방법 역시 시간이 흐르면서 내부의 구분을 지속적으로 관리 안해주면 서로 결합하게 될 수 있으니 신경 써야 함

일차원 경계

원래 아키텍처의 경계는 쌍방향 Boundary 인터페이스를 사용함. 양방향으로 격리된 상태를 유지하려면 초기 설정할 때나 지속적으로 유지할 때도 비용이 많이 듦.
추후 완벽한 형태의 경계로 확장할 수 있는 공간을 확보하고자 할 때 활용할 수 있는 더 간단한 구조가 다음과 같음
이는 전통적인 Strategy 패턴을 사용한 사례임

의존성 역전이 적용되어 있지만 점선을 보면 이러한 분리는 매우 빠르게 붕괴될 가능성이 있음. 시간이 지날수록 둘의 의존성이 생기는 코드가 생길 수 있음

파사드

이것보다 훨씬 단순한 경계는 Facade 패턴으로, 이 경우에는 심지어 의존성 역전까지도 희생함. 경계는 단순히 Facade 클래스로만 간단히 정의됨. 파사드 클래스에는 모든 서비스 클래스를 메서드 형태로 정의하고, 서비스 호출이 발생하면 해당 서비스 클래스로 호출을 전달함. 클라이언트가 직접 접근하는 것을 막음.
하지만 클라이언트가 이 모든 서비스 클래스에 대해 추이 종속성을 가지게 됨. 정적 언어라면 서비스 클래스 중 하나에서 소스 코드가 변경되면 클라이언트도 무조건 재컴파일 해야 함. 이러한 구조면 비밀통로가 더 쉽게 만들어질 가능성이 높음

 

참고 및 출처: <클린 아키텍처> (로버트 C.마틴지음, 송준이옮김, 인사이트 , 2019)