[11] 33~34 사례 연구: 비디오 판매

23.11.4

[33] 사례 연구: 비디오 판매

<웹사이트에서 비디오를 판매하는 소프트웨어>

• 개인과 기업에게 판매한다.
• 개인은 구매자인 동시에 시청자이고, 스트리밍 혹은 영구 소지할 수 있다.
• 기업은 구매자와 시청자가 다르고, 스트리밍만 된다.

액터 기준으로 경계가 나뉨

-한 액터 기능이 변경되도 다른 액터에게 영향 없도록

-제작자, 관리자, 구매자, 시청자

-카탈로그 조회(View Catalog) 는 추상 클래스이다. 비슷한 기능이라서. 구매자, 시청자 단에서 각각 구현해줌. 

컴포넌트 아키텍처

-검정 화살표: 상속관계 / 빈 화살표: 제어 흐름. 고수준을 향해 있다.

-컨트롤러로 입력이 들어오면 interactions 에 의해 데이터가 만들어지고, 그 이후에 Presenters 가 결과 포맷 변경하고 Views 가 화면에 표시한다.

-Catalog View, Catalog Presenter 는 추상 클래스이다.

-각 컴포넌트는 각각의 .jar 로 독립적으로 배포될 수 있게 패키지 구조를 분할해 놓는다.

-두 가지의 분리 포함

• 단일 책임 원칙에 기반한 액터의 분리
• 의존성 규칙

→ 서로 다른 이유(액터 기능)로, 서로 다른 속도(정책 수준)로 컴포넌트를 분리하는데 목적이 있다.

[34] 빠져 있는 장

패키지에 대한 얘기

구현 할 것: 온라인 서점. 주문 상태를 조회할 수 있어야 함

계층 기반 패키지

• 웹, 업무 규칙, 영속성 코드
• 전통적인 수평 계층형 아키텍처
• 기술적인 관점에서 코드가 하는 일에 기반해 분할한다.
• 계층은 바로 아래 계층에만 의존해야 한다.
• 간단한 프로젝트에서 시작하기 좋지만, 규모가 커지고 복잡해질수록 이 세 개로 모든 코드를 담기엔 부족하고 잘게 쪼개는 방법을 고민해야 할 것이다.

 

기능 기반 패키지

• 계층 기반 패키지를 아주 간단히 리팩토링 한 형태
• 업무 도메인에 관한 파악이 쉽다 - 주문 관련한 무언가를 하는구자
• ‘주문 조회하기' 유스케이스가 변경되면 이 안에서 코드를 변경하면 되므로 변경할 코드 찾는 작업이 편하다.
• 하지만 위 두 개 패키지 구조는 차선책.

 

포트와 어댑터

= 헥사고날 아키텍처

• 업무/도메인에 초점을 둔 코드나 프레임워크, DB 같은 기술적인 세부규현에 독립적이고 분리된 아키텍처 만들기 위함
• 외부가 내부에 의존. 그 반대는 불가

예시

• OrdersRepository → Orders 로 바뀐 이유: DDD 에서 비로된 명명법. 내부에 존재하는 건 유비쿼터스 도메인 언어 관점에서 기술하라

 

컴포넌트 기반 패키지

계층 기반 패키지의 단점: 마음만 먹으면 계층을 넘나들 수 있다. (ex. Controller 에서 바로 Repository 호출)

이런 원칙을 강제하기 위해 정적 분석 도구로 아키텍처적인 위반 사항을 검사할 수는 있는데 컴파일 단계 끝나고 검사하는 거고 알게 되는 주기가 너무 길다.

→ 컴포넌트 기반이 나오게 된 이유라는데.. 컴포넌트 기반에서는 못하는 이유? protected 선언으로!

컴포넌트의 정의

• 배포할 수 있는 가장 작은 단위. (ex. jar 파일) - 엉클 밥
• 멋지고 깔끔한 인터페이스로 감싸진 연관된 기능들의 묶음. 애플리케이션같은 실행 환경 내부에 존재한다. 컴포넌트가 jar 파일로 분리될지 여부는 직교적인(관련없는) 관심사 - 저자(로버트 c 마틴)

 

캡슐화

 

레퍼런스

클린 아키텍처 33~34 장