06 세부사항 - 2

 

31장 웹은 세부사항이다

 

끝없이 반복하는 추

연산 능력을 중앙에 집중하는 방식과 분산하는 방식 사이에 끊임없이 움직임.

웸<- 클라이언트-서버 아키텍처<- 중앙집중식 미니컴퓨터<- 메인프레임<- ...

 

아키텍트는 이러한 움직임을 크게 바라보며 핵심 업무 규칙의 중심에서 밀어내고 싶은 단기적인 문제라고 생각해야 함.

 

업무 규칙을 UI로부터 분리해야한다.

마케팅에 의해 언제나 UI는 바뀔수 있으며, 사소한 결합이 만들어지는 순간 문제가 발생.

 

요약

GUI는 세부사항, 웹은 GUI. 따라서 웹은 세부사항이다.

이러한 세부사항을 핵심 업무로직에서 분리해 경계 바깥에 두어야 함.

웹은 입출력 장치일 뿐

 

업무 로직은 다수 유스케이스로 구성됨. 각 유스케이스는 사용자를 대신해 일부 함수를 수행.

각 유스케이스느 입력 데이터, 수행 처리과정, 출력데이터를 기반으로 기술.

 

완전한 입력 데이터와 그에 따른 출력 데이터는 데이터 구조로 만들어서 유스케이스를 실행하는 처리과정의 입력값과 출력값으로 사용.

이 방식으로 각 유스케이스가 장치 독립적인 방식으로 UI라는 입출력 장치를 동작시킨다고 간주.

결론

추상화를 제대로 만들기 쉽지않음. 반복 과정이 필요.

 

---

32장 프레임워크는 세부사항이다.

프레임워크는 아키텍처가 될 수 없다.

 

프레임워크 제작자

프레임워크 제작자는 자신이 해결해야할 고유한 문제를 해결하기위해 프레임워크를 만드는 것.

나의 문제가 프레임워크가 풀려는 문제와 많이 겹치기 때문에 살제로 유용하고 인기를 얻은 것.

혼인관계의 비대칭성

프레임워크 문서에서는 우리가 만들 소프트웨어와 프레임워크를 어떻게 통합할 수 있을지 조언.

프레임워크 제작자는 애프리케이션이 가능하면 프레임워크에 결합될 것을 역설.

프레임워크에 대해 장기간 헌신을 요청하지만, 모든 위험은 사용자가 감당해야한다.

 

위험요인

• 프레임워크의 아키텍처는 깔끔하지 않은 경우가 많음.
  업무 객체가 강하게 결합되어 의존성 규칙을 위반하는 경향.
• 프레임워크는 애플리케이션 초기 기능을 만드는데 도움이 되지만,
  제품이 성숙해지면 제공 기능과 틀에서 벗어나게 됨.
• 프레임워크가 내가 원하는 방향으로 진화하지 않을수 있음.
• 새로운 프레임워크로 옮길 가능성.

해결책

-> 프레임워트와 강하게 결합하지 말라.

 

프레임워크가 핵심 코드 안으로 들어오지 못하게 하라.

업무객체 보다는 메인 컴포넌트에서 스프링을 사용해 의존성 주입하는게 낫다.

 

이제 선언합니다.

C++의 경우 STL과 자바의 경우 표준라이브러리와는 반드시 결합해야 함.

이것은 정상이지만 선택적이 될수도.

 

결론

프레임워크와 처음부터 결혼하려 들지 말라.

가급적 프레임워크를 오랫동안 아키텍처 경계 너머에 두자.

 

---

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

아티텍처에 대한 규칙과 견해를 종합한 사례 연구.

아키텍트가 일을 처리하는 과정과 결정을 내리는 모습.

제품

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

개인과 기업에게 웹을 통해 판매. 

 

개인은 단품 스트리밍하거나 다운로드 소장.

기업은 스트리밍전용으로 대량구매 할인가능.

개인은 시청자이자 구매자이며, 기업은 시청할 비디오 구매자가 따로 있음.

비디오 제작자는 비디오 파일과 설명서, 부속 파일 제공.

관리자는 신규 비디오 추가하거나 기존 시리즈에 추가, 삭제. 라이선스에 가격 책정.

 

유스케이스 분석

 

네개의 주요 액터. 

단일 책임 원치에 따라 네 액터가 시스템이 변경되어야 할 네가지 주요 근원.

전형적 유스케이스 분석

 

시스템을 분할해 특정 액터를 위한 변경이 나머지 액터에게 영향을 미치지 않게 만들어야 함.

 

중앙의 점선은 추상 유스케이스. 범용적 정책을 담고 있음. 

시청자와 구매자 카탈로그 조회하기 유스테이스 모두 카탈로그 조회 추상 유스케이스 상속받음.

컴포넌트 아키텍처

액터와 유스케이스 식별 후 예비단계 컴포넌트 아키텍처 구성.

 

예비단계 컴포넌트 아키텍처

이중선은 아키텍처 경계

 

View, Presenter, Interactor, Controller 로 분리된 전형적 분할.

대응하는 액터에 따라 카테고리 분리.

각 컴포넌트는 단일 .jar 파일, 단일 .dll 파일에 해당.

컴포넌트 각각 자신에게 할당된 뷰, 프레젠터, 인터랙터, 컨트롤러 포함.

 

컴포넌트를 독립적으로 전달할 수 있게 빌드 배포 가능.

뷰와 프레젠터를 합쳐 같은 .jar에 두고 인터랙터, 컨트롤러, 유틸리티는 개별 .jar파일에 두는 방식도 가능.

선택지를 열어두어 이후 변경에 맞춰 시스템 배포방식 조절.

의존성 관리

제어흐름은 오른쪽에서 왼쪽으로 이동.

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

 

사용관계(열린 화살표)는 제어흐름과 같은 방향을 가리키며,

상속관계(닫힌 화살표)는 제어흐름과 반대 방향을 가리킨다. 

-> 개방 폐쇄 원칙 적용. 의존성이 올바른 방향. 저수준 변경이 상위로 파급되어 상위 수준의 정책에 영향을 미치지 않음.

 

결론

컴포넌트 아키텍처 다이어그램의 분리 개념

1. 단일 책임 원칙에 기반한 액터의 분리.

2. 의존성 규칙.

 

이후 상황에 맞게 컴포넌트 단위를 바꿔 배포 가능.