‘클린 아키텍처’ 기술 서적에 대해 학습했던 내용을 정리하기 위한 목적의 TIL 포스팅입니다.🙆♂️
유스케이스 분석
출처: https://skidrow6122.tistory.com/25
- 단일 책임 원칙에 따르면 이들 네 액터(제작자, 관리자, 구매자, 시청자)가 시스템이 변경되어야할 네 가지 주요 근원이 된다.
- 신규 기능을 추가하거나 변경해야한다면 반드시 이들 엑터중 하나에게 해당 기능을 제공하기 위해서다.
- 따라서 시스템을 분할하여, 특정 액터를 위한 변경이 나머지 액터에게는 전혀 영향을 미치지 않게 만들어야함
- 중앙 점선으로된 유스케이스는 추상 유스케이스(‘카탈로그 조회’)고 이는 다른 유스케이스(‘구매자 입장에서 카탈로그 조회’, ‘시청자 입장에서 카탈로그 조회’)에 의해 구체화된다.
컴포넌트 아키텍처
출처: https://skidrow6122.tistory.com/25
- view, presenter, interactor, controller 로 분할하였고 또한 대응하는 액터에 따라 카테고리로 분리하였다.
- 각 컴포넌트는 .jar 혹은 .dll 파일에 해당한다. 이는 변경되는 시스템 상황에 맞게 더 쪼개지거나 합쳐져서 배포 방식을 자유롭게 만든다.
의존성 관리
- 모든 의존성은 경계선을 한 방향으로만 가르지르는데, 항상 더 높은 수준의 정책(interactors)을 포함하는 컴포넌트를 향한다.
- 사용 관계(열린 화살표)는 제어 흐름과 같은 방향을 가리키며, 상속 관계(닫힌 화살표)는 제어흐름과는 반대 방향을 가리킨다. 이는 개방 폐쇄 원칙을 적용했음을 보여준다.
- 저수준의 세부사항에서 발생한 변경이 상위로 파급되어서 상위 수준의 정책에 영향을 미치지 않음을 보장할 수 있다.
결론
- 그림 33.2의 아키텍처 다이어그램은 두 가지 서로 다른 차원의 분리 개념을 포함하고 있다.
- 하나는 단일 책임 원칙에 기반한 액터의 분리, 두 번째는 의존성 규칙
- 이 두 차원은 모두 서로 다른 이유로, 서로 다른 속도로 변경되는 컴포넌트를 분리하는데 그 목적이 있다.
- 서로 다른 이유라는 것은 액터와 관련 있으며, 서로 다른 속도라는 것은 정책 수준과 관련있다.
- 이런 방식으로 코드를 한번 구조화하고 나면 시스템을 실제로 배포하는 방식은 다양하게 선택할 수 있게 된다. 상황에 맞게 컴포넌트들을 배포 가능한 단위로 묶을수도 있고, 상황이 변하면 변한 상황에 맞춰 묶는 단위를 바꾸기도 쉬워진다.