아키텍처 - 부분적인 경계

- 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.)

- 개요

아키텍처 경계를 완벽하게 하는데에는 비용이 많이 든다. 양방향으로 인터페이스를 정의하고, 입력과 출력에 대한 데이터 구조를 만들며, 독립적으로 컴파일 및 배포를 할 수 있도록 컴포넌트를 설계하고 의존성을 관리해야 한다.

 

이런 이유로 어떤 사람들은 경계를 완벽하게 만드는것이 과도하게 선행적인 설계라고 생각한다. 너무 완벽한 경계를 구현하는데 과도한 비용이 들어간다면 경계를 부분적으로 구현하는것을 고려해볼 수 있다.

---

- 단일배포

첫번째 방법으로는 소스는 완벽한 경계를 구현하지만, 단일 컴포넌트로 컴파일해서 배포하는것이다. 이렇게 되면 코드는 간단해지지 않지만 의존성이나 버전관리를 하지 않아도 된다.

 

무슨 차이가 있냐고 생각할수도 있지만 컴포넌트간 의존성관리를 하지 않아도 된다는 점과 버전관리를 하지 않아도 되는 공수는 생각보다 클수도 있다.

---

- 일차원 경계

일차원 경계는 추후 완벽한 경계를 구축해야 하는 상황에 대비도 가능하면서 경계를 구분하는 간단한 구조의 구현방식이다.

 

아래 다이어그램은 어딘가 모르게 익숙한 느낌을 준다. 클라리언트를 Controller나 다른 Service로 바꾼다면 우리가 스프링을 사용해서 웹 어플리케이션을 구축하는데 쓰는 컨트롤러, 서비스의 전형적인 구조와 많이 닮아있다.

 

아래 경계구조는 Client로 부터 Service Impl 을 분리하였다. 다만 Danger라고 표시되어있는 점선 화살표와 같은 의존성을 사용하지 않도록 유의해야 한다.

---

- 퍼사드

일차원 경계보다 더 간단한 전략이다. 아래 다이어그램에서 Facade 자체가 경계가 된다. Client 는 Service1, 2에 직접 접근할 수 없고 Facade 클래스를 이용해 Service1, 2의 메소드를 호출한다.

 

이런 의존성 구조에서 Client 는 Service 1, 2에 대해 추이 종속성을 가지게 된다. 또한 프로그래머가 마음만 먹으면 일차원 경계보다 더 위험한 의존성을 사용할 수 있다.

---

- 결론

아키텍처의 경계를 구현하는 방법은 꼭 세 가지만 있는것은 아니다. "아키텍처라면 무조건 양방향 인터페이스를 만들어서 경계를 완벽하게 구분해야 한다. 그것이 원칙에 맞기 때문에" 라고 생각하기 보다는 상황에 따라 부분적인 경계로도 충분한지 판단하여 구현할지를 생각해볼 필요가 있다.