지금까지 살펴본 아키텍처에 대한 규칙과 견해를 종합해서 사례 연구로 적용해 볼 차례다.
제품
- 웹 사이트에서 비디오를 판매하는 소프트웨어
- 소프트웨어의 기본적인 발상은 단순히, 판매하길 원하는 비디오들이 있고 그걸 개인과 기업에게 웹을 통해 판매하는 것임.
- 시스템의
초기 아키텍처를 결정하는 첫 단계는 액터와 유스케이스를 식별하는 일이다.
유스케이스 분석
- 네 개의 주요 액터는 분명하다. 단일 책임 원칙에 따르면 이들 네 액터가 시스템이 변경되어야 할 네 가지 주요 근원이 된다. 신규 기능을 추가하거나 기존 기능을 변경해야 한다면, 그 이유는 반드시 이들 액터 중 하나에게 해당 기능을 제공하기 위해서다.
컴포넌트 아키텍처
- 액터와 유스케이스를 식별했으므로, 예비 단계의 컴포넌트 아키텍처를 만들어 볼 수 있다.
- 뷰, 프레젠터, 인터랙터, 컨트롤러로 분리된 전형적인 분할 방법을 확인할 수 있다.
- 또한 대응하는 액터에 따라 카테고리를 분리했다는 사실도 확인할 수 있다.
- 특수한 컴포넌트인 Catalog View와 Catalog Presenter에 주목해보면, 카탈로그 조회하기라는 추상 유스케이스를 처리하는 엉클 밥만의 방식임. 해당 컴포넌트 내부에서 추상 클래스로 코드화 되고 상속 받는 컴포넌트에서는 이들 추상 클래스로부터 상속받은 뷰와 프레젠터 클래스들을 포함한다.
의존성 관리
- 위 컴포넌트 아키텍처에서 제어흐름은 오른쪽에서 왼쪽으로 이동함
- 입력이 컨트롤러에서 발생하면 인터랙터에 의해 처리되어 결과가 만들어진다. 그런 후 프레젠터가 결과의 포맷을 변경하고, 뷰가 화면에 표시한다.
- 대다수의 화살표는 왼쪽에서 오른쪽으로 향한다. 이는 아키텍처가 의존성 규칙을 준수하기 때문.
결론
위의 아키텍처 다이어그램은 두 가지 서로 다른 차원의 분리 개념을 포함하고 있다.
- 하나는 단일 책임 원칙에 기반한 액터의 분리
- 다른 하나는 의존성 규칙이다.
이 두 차원은 모두 서로 다른 이유로, 서로 다른 속도로 변경되는 컴포넌트를 분리하는 데 그 목적이 있다.
서로 다른 이유라는 것은 액터와 관련이 있으며, 서로 다른 속도라는 것은 정책 수준과 관련이 있다.
이런 방식으로 코드를 한번 구조화하고 나면 시스템을 실제로 배포하는 방식은 다양하게 선택할 수 있게 된다.