33장 사례 연구: 비디오 판매

제품

 

아키텍처를 적용해볼 사례로 소프트웨어 튜토리얼 비디오를 판매하는 "소프트웨어 제품" 시스템의 초기 아키텍처를 결정짓는 첫 단계는 액터와 유스케이스를 식별하는것임.

 

 

 

유스케이스 분석

 

 

액터의 관점에서 책임을 정의할 수 있는 단일책임 원칙에 따르면 네 액터가 시스템이 변경되어야 할 네 가지 주요 근원이 됨.

특정 액터의 변경이 나머지 액터에게는 전혀 영향을 미치지 않게 해야함.

중앙 점섬으로된 유스케이스는 추상유스케이스임.

이는 범용적인 정책을 담고있으며 다른 유스케이스에서 이를 더 구체화시킴.

시청자, 구매자입장에서 카탈로그 조회하기는 추상 카탈로그 조회하기 유스케이스를 상속함.

→ 추상 유스케이스는 저자만의 방법임, <<abstract>> UML 스테레오타입을 사용해도 무난.

 

 

 

컴포넌트 아키텍처

 

유스케이스 식별 후 예비단계 컴포넌트 아키텍처를 만들어 봄.

 

 

추상유스케이스로 특수한 컴포넌트인 Catalog View와 Catalog Presenter는 해당 컴포넌트 내부에 추상클래스로 코드화되며 이를 상속받는 컴포넌트는 추상클래스로부터 상속받은 뷰와 프레젠터 클래스를 포함함.

 

각 컴포넌트는 단일 .jar에 해당할 수 있지만 경계를 구분해서 뷰, 프레젠터, 인터렉트, 컨트롤러, 유틸리티 각각을 하나의 jar로 구분할 수 있음. 또한 뷰와 프레젠터를 같은 .jar에 두고 나머지는 개별로 둘 수 있으며 이처럼 각 컴포넌트들이 독립적으로 컴파일하고 빌드할 수 있는 환경으로 구성되게끔 선택지를 열어두면 시스템이 변경되는 양상에 맞춰 배포방식을 조절할 수 있음.

 

 

 

의존성관리

 

입력이 컨트롤러에서 발생되면 인터랙터에 의해 처리되며 프레젠터가 결과의 포맷을 변경하고 뷰가 화면에 표시됨.

 

아키텍처가 의존성 규칙을 준수하기 때문에 모든 의존성은 항상 더 높은 수준의 정책을 포함하는 컴포넌트로 향함.

 

사용관계(색칠된화살표)는 제어흐름과 같은방향을 가리키며 상속관계(색칠되지 않은 화살표)는 제어흐름과는 반대 방향을 가리킴.

 

Admin Presenters는 Admin Interactors보다 저수준이기 때문에 Admin Interactors가 Admin Presenters를 의존하여 사용하지 않고 Admin Presenters가 Admin Interactors컴포넌트에 포함된 인터페이스를 상속하여 구현하며 Admin Interactors는 이 인터페이스를 의존하여 의존성 역전이 되게끔함. 이는 저수준의 세부사항의 변경이 고수준에 영향을 미치지 않게하는 개방 폐쇄원칙을 적용했음을 보여줌.

 

 

 

결론

 

 

위는 서로다른이유(액터의 분리), 서로다른속도(정책 수준)로 두가지 서로 다른 차원의 분리 개념을 포함하고있음.

→ 이런방식으로 코드를 구조화 하면 시스템을 실제로 배포하는 방식을 다양하게 선택가능함.