사례연구: 비디오 판매

사례연구 의의

• 사례를 통해 지금까지 살펴 보았던 아키텍처에 대한 규칙과 견해를 종합적으로 살펴본다.
• 뛰어난 아키텍트가 일을 처리하는 과정과 결정을 내리는 모습을 볼 수 있다.

제품

• 제품은 웹 사이트에서 비디오를 판매하는 소프트웨어이다.

  • 판매하길 원하는 비디오가 있으며, 개인과 기업에게 웹을 통해 판매한다.
  • 구매자
    • 개인
      • 단품 가격을 지불해 스트리밍으로 보거나, 더 높은 가격을 내고 비디오를 다운로드해서 영구 소장 가능.
    • 기업
      • 기업용 라이선스는 스트리밍 전용이며, 대량 구매를 하면 할인을 받을 수 있다.
      • 기업은 다른 사람들이 시청할 비디오를 구매하는 사람이 따로 있다.
  • 시청자
  • 비디오 제작자
    • 비디오 파일과 비디오에 대한 설명서, 부속 파일(시험, 문제, 해법, 소스 코드 등)을 제공해야 한다.
  • 관리자
    • 신규 비디오 시리즈물을 추가하거나 기존 시리즈물에 비디오를 추가 또는 삭제하며, 다양한 라이선스에 맞춰 가격을 책정한다.

• 시스템의 초기 아키텍처를 결정하는 첫 단계인 액터와 유스케이스를 식별 해보자!

유스케이스 분석

이미지 출처 : https://hwannny.tistory.com/51

• 단일 책임 원칙
  • 단일 책임 원칙에 따라 네 '제작자, 관리자, 구매자, 시청자' 네 액터가 시스템이 변경되어야 할 네 가지 주요 근원이 된다.
  • 신규 기능을 추가하거나 기존 기능을 변경해야 한다면, 그 이유는 반드시 이들 액터 중 하나에게 해당 기능을 제공하기 위해서다.
• 중앙의 점선 유스케이스
  • 추상 유스케이스다.
  • 범용적인 정책을 담고 있으며, 다른 유스케이스에서 이를 더 구체화한다.
  • 카탈로그 조회하기 유스케이스는 모두 카탈로그 조회하기라는 추상 유스케이스를 상속받는다.
  • 이러한 추상화가 반드시 필요한 작업은 아니었음. 다이어그램에 없더라도 전체 제품의 기능을 조금도 손상시키지 않음. 단지 이들 두 유스케이스가 너무 비슷해서 유사성을 식별해서 분석 초기에 통합하는 방법을 찾는 편이 더 현명하다고 판단하였음.

컴포넌트 아키텍처

이미지 출처 : https://hwannny.tistory.com/51

• 액터와 유스케이스를 식별했으므로, 예비 단계의 컴포넌트 아키텍처를 만들어 볼 수 있다.
• 이중선은 아키텍처 경계를 나타내며, 이 아키텍처는 뷰 / 프레젠터 / 인터렉터 / 컨트롤러라는 전형적인 분할법을 적용함.
• 또한 대응하는 액터에 따라 카테고리를 분리했다.
• 각 컴포넌트는 단일 .jar 파일 또는 단일 .dll 파일에 해당한다.
  • 이들 컴포넌트 각각은 자신에게 할당된 뷰, 프레젠터, 인터렉터, 컨트롤러를 포함한다.
• 특수한 컴포넌트인 Catalog View와 Catalog Presenter는 해당 컴포넌트 내부에 추상 클래스로 코드화될 것이며, 상속받는 컴포넌트에서는 이들 추상 클래스로부터 상속받은 뷰와 프레젠터 클래스들을 포함한다.
• 각 컴포넌트는 단일 .jar에 해당할 수 있지만 경계를 구분해서 뷰, 프레젠터, 인터렉터, 컨트롤러, 유틸리티 각각을 하나의 jar로 구분할 수 있음. 또한 뷰와 프레젠터를 같은 .jar에 두고 나머지는 개별로 둘 수 있으며 이처럼 각 컴포넌트들이 독립적으로 컴파일하고 빌드할 수 있는 환경으로 구성되게끔 선택지를 열어두면 시스템이 변경되는 양상에 맞춰 배포방식을 조절할 수 있음.

의존성 관리

• 입력이 컨트롤러에서 발생하면 인터랙터에 의해 처리되고 프레전터가 결과의 포맷을 변경하고 뷰가 화면에 표시된다.
• 아키텍처가 의존성 규칙을 준수하기 때문에 모든 의존성은 경계선을 한 방향으로만 가로지르는데, 항상 더 높은 수준의 정책을 포함하는 컴포넌트를 향한다.
• 개방 폐쇄 원칙을 적용했기 때문에 사용관계(열린 화살표)는 제어흐름과 같은 방향을 가리키며, 상속관계(닫힌 화살표)는 제어흐름과는 반대 방향을 가리킨다.

결론

• 이 아키텍처는 두 가지 서로 다른 차원의 분리 개념을 포함한다.
  • 단일 책임 원칙에 기반한 액터의 분리
  • 의존성 규칙
• 이 두 차원은 모두 서로 다른 이유로 서로 다른 속도로 변경되는 커모넌트를 분리하는 데 그 목적이 있다.
• 서로 다른 이유라는 것은 액터와 관련, 서로 다른 속도라는 것은 정책 수준과 관련
• 이렇게 구조화하면 시스템을 실제로 배포하는 방식은 다양하게 선택가능해진다.
• 컴포넌트들을 배포 가능한 단위로 묶을 수도 있고, 묶는 단위를 바꾸기도 쉬워진다.