양방향 Boundary 인터페이스가 왜 꼭 필요할지.. InputBoundary는 이해가 가는데 OutputBoundary는 특이 케이스..? 우리가 주로 사용하는 REST 형태의 웹서버에는 필요가 없어보이는데
서론
아키텍처 경계를 완벽하게 만드는 데는 비용이 많이 든다. 쌍방향의 다형적 Boundary 인터페이스(Untitled의
InputBoundary, OutputBoundary), Input과 Output을 위한 데이터 구조를 만들어야 할 뿐아니라, 두 영역을 독립적으로 컴파일하고 배포할 수 있는 컴포넌트로 격리하는 데 필요한 모든 의존성을 관리해야 한다. 이렇게 만들려면 엄청난 노력을 기울여야 하고, 유지하는 데도 또 엄청난 노력이 든다.애자일 커뮤니티에 속한 사람 중 많은 이가 이러한 종류의 선행적인 설계를 탐탁지 않게 여기는데, YAGNI(You aren’t going to need it )원칙을 위배하기 때문임. 하지만 아키텍트라면 필요할거라고 생각할 수도 있기에 그런 상황에서는 부분적 경계를 구현해 볼 수 있다
부분적 경계
1. 마지막 단계를 건너뛰기
- 부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 두는 것임
- 쌍방향 인터페이스도 그 컴포넌트에 있고, 입력.출력 데이터 구조도 거기에 있으며, 모든 것이 완전히 준비되어 있다. 하지만 이 모두를 단일 컴포넌트로 컴파일해서 배포한다.
- 다수의 컴포넌트를 관리하는 작업은 하지 않아도 되어 추적을 위한 버전 번호, 배포 관리 부담도 없음
- 단점 : 시간이 흐르면서 각 컴포넌트별 구분이 약화되며 의존성이 잘못된 방향으로 선을 넘을 수 있음. 이런 것들의 구분을 다시 해야 할 수 있음
2. 일차원 경계
완벽한 형태의 아키텍처 경계는 양방향으로 격리된 상태를 유지해야 하여 쌍방향 Boundary 인터페이스를 사용함. 양방향으로 격리된 상태를 유지하려면 초기 설정할 때나 지속적으로 유지할 때도 비용이 많이 든다.
위와 같이 전략 패턴 형태로 1차원 경계만 사용하면 양방향 인터페이스를 사용할 때보다는 간편하다
쌍방향 인터페이스가 없고 개발자와 아키텍트가 근면 성실하고 제대로 훈련되어 있지 않다면, ServiceImpl에서 Client로 가는 점선과 같은 비밀 통로가 생기는 일을 막을 방법이 없음
일차원 경계는 InputBoundary와 OutputBoundary 중 하나만 사용하는 것인 것 같음(한쪽은 Interface를 두지 않고 바로 의존성을 갖게 되는것)
양방향 경계는 InputBoundary와 OutputBoundary 둘 다를 사용하는 것이고.
3. 퍼사드
- 위의 방법보다 훨씬 더 단순한 경계는 퍼사드(Facade) 패턴으로 이 경우에는 심지어 의존성 역전까지도 희생함
- 경계는 Facade 클래스로만 간단히 정의되며 Facade 클래스의 메서드를 호출 시 해당 호출을 서비스 클래스의 메서드를 호출하며 전달함. 클라이언트는 이들 서비스 클래스에 직접 접근할 수 없음
- 단점
- 하지만 이 방법을 이용하면 Client가 모든 서비스 클래스에 대해 추이 종속성을 가지게 됨으로 정적 언어였다면 서비스 클래스 중 하나에서 소스코드가 변경되면 Client도 무조건 재컴파일해야 함
- 이러한 구조라면 비밀 통로 또한 정말 쉽게 만들 수 있음
결론
아키텍처 경계를 부분적으로 구현하는 간단한 방법 세가지를 살펴봄. 이 외에도 방법은 많지만 순전한 예로써 세가지가 제시 되었음.
이러한 접근법 각각은 나름의 비용과 장점을 지니고, 각 접근법은 완벽한 형태의 경계를 담기 위한 공간으로써, 적절하게 사용할 수 있는 상황이 서로 다르다. 또한 각 접근법은 해당 경계가 실제로 구체화되지 않으면 가치가 떨어질 수 있다.