클린 아키텍처 #4

2022.01.07 - [Study/컴퓨터 공학] - 클린 아키텍처

2022.01.11 - [Study/컴퓨터 공학] - 클린 아키텍처 #2

2022.01.18 - [Study/컴퓨터 공학] - 클린 아키텍처 #3

2022.03.02 - [Study/컴퓨터 공학] - 클린 아키텍처 #5

2022.05.16 - [Study/컴퓨터 공학] - 클린 아키텍처 #6

클린 아키텍처 : 4부 14장까지 

---

저자 : 로버트 C. 마틴
출판 : 인사이트
출간 : 2019.08.20.

학습 방법 : 책을 읽고 소제목 단위로 핵심 내용을 1~3문장 정도로 요약

---

4부.

⦿ 컴포넌트 원칙

✓ SOLID 원칙보다 더 큰 규모에서의 원칙이다.

12장 컴포넌트

✓ 컴포넌트는 시스템 구성 요소로 배포될 수 있는 가장 작은 단위다(jar, gem, dll 등).
✓ 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다.

⦿ 컴포넌트의 간략한 역사

✓ 메모리를 직접 관리하는 어려움을 극복하려는 노력으로 만들어짐

⦿ 재배치성

✓ 재배치 가능한 바이너리로 문제 해결
✓ 링킹 로더가 이러한 역할을 수행

⦿ 링커

✓ 과거의 상황 : 느린 하드웨어에 점점 커지는 프로그램
✓ 링커와 로더의 분리 : 링크는 여전히 느리지만 프로그램 실행은 빨라짐
✓ 상황의 변화 : 하드웨어의 발전으로 속도가 빨라짐에 따라 다수의 공유 라이브러리를 링크하는 속도 역시 빨라짐
✓ 컴포넌트 플러그인 아키텍처 탄생

⦿ 결론

✓ 런타임 시 플러그인 형태로 결합할 수 있는 동적 링크 파일이 소프트웨어 컴포넌트에 해당한다.

 

13장 컴포넌트 응집도

✓ 클래스를 컴포넌트에 배치하는 원칙
✓ 컴포넌트 응집도와 관련된 3가지 원칙
- REP : 재사용 / 릴리스 등가 원칙
- CCP : 공통 폐쇄 원칙
- CRP : 공통 재사용 원칙

⦿ REP: 재사용/릴리스 등가 원칙

“ 재사용 단위는 릴리스 단위와 같다.

✓ 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 한다.
✓ 따라서 하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 하며, 동일한 릴리스로 추적 관리되고, 동일한 릴리스 문서에 포함되어야 한다.

⦿ CCP: 공통 폐쇄 원칙

✓ 동일한 시점에 변경되는 클래스는 같은 컴포넌트로 묶어라. 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라.
✓ SRP(단일 책임의 원칙)의 컴포넌트 버전
✓ OCP(개방 폐쇄 원칙)의 폐쇄와 동일한 의미

⦿ CRP: 공통 재사용 원칙

✓ 컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라
✓ 같이 재사용되는 경향이 있는 클래스와 모듈은 같은 컴포넌트에 포함해야 한다(망치와 못, 나사와 드라이버).
✓ 어떤 클래스를 한데 묶어서는 안되는지가 더 중요.
✓ ISP(인터페이스 분리 원칙)의 컴포넌트 버전

⦿ 컴포넌트 응집도에 대한 균형 다이어그램

✓ REP와 CCP는 포함의 원칙, CRP는 배제의 원칙

⦿ 결론

✓ 프로젝트가 진행됨에 따라 상황이 달라지게 됨
✓ 3가지 원칙의 균형점을 잡는 것이 중요

 

14장 컴포넌트 결합

✓ 개발 가능성과 논리적 설계 사이의 균형이 중요
✓ 컴포넌트 구조와 관련된 아키텍처를 침범하는 힘은 기술적이며, 정치적이고, 가변적이다.

⦿ ADP: 의존성 비순환 원칙

✓ 컴포넌트의 의존성 그래프에 순환이 있어서는 안된다.
✓ 순환 의존성이 존재할 경우 동일한 소스를 다수의 개발자들이 수정할 때 문제가 발생
✓ 순환 끊기의 두 가지 메커니즘
- DIP(의존성 역전) 원칙을 적용
- 공통으로 의존하는 클래스들을 새로운 컴포넌트로 묶는다.
✓ 항상 의존성 구조에 순환이 발생하는지를 살피고, 발생하면 반드시 끊어야 한다.

⦿ 하향식(top-down) 설계

✓ 컴포넌트 구조는 하향식으로 설계될 수 없으며 시스템의 성장하고 변경될 때 함께 진화함
✓ 컴포넌트 의존성 다이어그램은 애플리케이션의 빌드 가능성과 유지보수성을 보여주는 지도

⦿ SDP: 안정된 의존성 원칙

✓ 안전성의 방향으로(더 안정된 쪽에) 의존하라.
✓ 안정성: 변경을 만들기 위해 필요한 작업량과 관련
✓ 안정성 지표: 컴포넌트로 들어오가 나가는 의존성의 개수를 계산(#include나 import 문으로 계산 가능)
✓ DIP(의존성 역전) 원칙으로 문제 해결
✓ 추상 컴포넌트의 사용

I지표 : 불안정성(I) = 밖으로 나가는 의존성 / (안으로 들어오는 의존성 + 밖으로 나가는 의존성)

⦿ SAP: 안정된 추상화 원칙

✓ 컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
✓ 고수준 아키텍처나 정책 결정과 관련된 소프트웨어는 자주 변경해서는 안된다.
✓ 컴포넌트가 최고로 안정된 상태이면서도 변경에 충분히 대응할 수 있게 만드는 방법: OCP(개방 폐쇄 원칙) 사용
✓ 안정적인 컴포넌트라면 반드시 인터페이스와 추상 클래스로 구성되어 쉽게 확장할 수 있어야 한다.

A 지표: 추상화 정도(A) = 컴포넌트의 클래스 수 / 컴포넌트의 추상 클래스와 인터페이스 수

✓ 고통의 구역: 변동성이 있는 컴포넌트가 문제
✓ 쓸모 없는 구역: 구현체가 없는 인터페이스
✓ 주계열: 가장 이상적인 컴포넌트가 위치

주계열과의 거리(D) = |A + I -1|

⦿ 결론

✓ 지표를 통한 측정은 시사하는 바가 있지만 완벽한 것은 아니다.