[책 정리] 33. 사례 연구 : 비디오 판매 - Clean Architecture

제품

 

 

 

유스케이스 분석

 

 

-

단일 책임 원칙에 따르면 이들 엑터가 시스템이 변경되어야 할 네 가지 주요 근원이 된다.

신규 기능을 추가하거나 기존 기능을 변경해야 한다면, 그 이유는 반드시 이들 액터 중 하나에게 해당 기능을 제공하기 위해서다.

따라서 우리는 시스템을 분할하여, 특정 엑터를 위한 변경이 나머지 액터에게는 영향을 미치지 않게 만들어야 한다.

 

 

-

점선으로 둘러싸인 유스케이스는 추상 유스케이스이다.

이들은 범용적인 정책을 담고 있으며, 다른 유스케이스에서 이를 더 구체화한다.

(추상 유스케이스가 꼭 필요하지는 않다.)

 

 

 

컴포넌트 아키텍처

 

 

-

View, Presenter, Interator, Controller 로 분리된 전형적인 분할 방법을 사용할 수 있다.

이중 선은 아키텍처 경계를 나타낸다.

뷰, 프레젠터, 인터렉터, 컨트롤러, 유틸리티 각각을 하나의 .jar 혹은 .dll 로 만들 수 있다.

좀 더 원시적으로, 뷰와 프레젠터를 하나에, 다른 하나에는 나머지 모두를 포함시키는 .jar 혹은 .dll 을 만드는 방법도 있다.

이 컴포넌트들을 모두 분할해서 여러 개의 .jar 나 .dll 로 전달해야 할까? 그럴 수도 있고 아닐 수도 있다.

 

 

 

의존성 관리

 

-

제어흐름은 항상 단방향으로 이동한다.

입력이 컨트롤러에서 발생하면 인터렉터에 의해 처리되어 결과가 만들어진다.

그런 후 프레젠터가 결과의 포맷을 변경하고, 뷰가 화면에 표시한다.

 

 

-

모든 의존성은 경계선을 한 방향으로만 가로지르는데, 항상 더 높은 수준의 정책을 포함하는 컴포넌트를 향한다.

사용 관계(열린 화살표)는 제어흐름과 같은 방향을 가리키며, 상속 관계(닫힌 화살표)는 제어흐름과는 반대 방향을 가리킴에 주목하자.

이는 개방 폐쇄 원칙을 적용했음을 보여준다.

이를 통해 우리는 의존성이 올바른 방향으로 흐르며, 따라서 저수준의 세부사항에서 발생한 변경이 상위로 파급되어서 상위 수준의 정책에 영향을 미치지는 않음을 보장할 수 있다.

 

 

 

결론

 

-

단일 책임 원칙에 기반하는 액터의 분리, 의존성 규칙을 지켜야 한다.

이를 지켜 코드를 한번 구조화하고 나면 시스템을 실제로 배포하는 방식은 다양하게 선택할 수 있게 된다.

상황에 맞게 컴포넌트들을 배포 가능한 단위로 묶을 수도 있고, 상황이 변하면 변한 상황에 맞춰 묶는 단위를 바꾸기도 쉬워진다.

 

끝