클린아키텍처 3주차

스터디 범위 12장 ~ 14장

참여자 총 7명

• @LIAM
• @BRANDON
• @CHRIS
• @LEO
• @PARKER
• @ODIN
• @BUZZ

12장 - 컴포넌트

• 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다.
• 잘 설계된 컴포넌트는 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야한다.
• 개발 초장기에 함수라이브러리에 더 많은 함수를 추가하며 할당된 메모리 주소를 넘어서게 되고, 결국 추가 공간을 할당해야 한다. 사용하는 메모리가 늘어날 수로 이와 같은 단편화는 계속 될 수 밖에 없다.
  

• 재배치성 : 위와 같은 해결책은 재배치가 가능한 바이너리. 지능적인 로더를 사용해 메모리에 재배치 할 수 있는 형태의 바이너리를 생성하도록 컴파일러를 수정. - 링킹로더
• 링커 : 링크가 완료된 재배치 코드를 만들어 주어 로더의 로딩을 아주 빠르게 만들었다.

13장 - 컴포넌트 응집도

- REP: 재사용/릴리즈 등가 원칙
  - 릴리즈 번호로 버전을 통한 관리, 버전 내역을 통해 적용 여부를 결정 한다
  - 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리즈할 수 있어야 한다 → 컴포넌트를 목적과 테마에 맞게 잘 구분지어서 포함해야 한다
- CCP: 공통 폐쇄 원칙
  - 동일한 시점에 변경되는 클래스는 묶고, 다른 시점에 변경되는 클래스는 분리
  - `유지보수성`을 위함 ( 변경 시 최소한의 컴포넌트만 작업 대상으로 하기 위해 )
- CRP: 공통 재사용 원칙
  - 컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라
  - 인터페이스 분리 원칙(ISP)의 포괄적인 버전 → 필요하지 않는 것에 의존하지 말아라 ( 사용하지 않는 import에 의해서 build 실패 사례)

컴포넌트 응집도에 대한 균형 다이어그램
→ Java lombok (@RequiredArgsConstructor, @Data, @Builder 등등 )
→ 여러 관계가 형성 되었을 때, 추가적인 변경이나 처리가 필요 없다. Java @Autowired 에서 extends시 전부다 super로 올릴 생성자를 선언해줘야 할때 등

14장 - 컴포넌트 결합

• ADP(Acyclic Dependencies Principle): 의존성 비순환 원칙

  컴포넌트 의존성 그래프에 순환cycle이 있어서는 안 된다.

순환이 컴포넌트 의존성 그래프에 미치는 영향

이 순환은 즉각적인 문제를 일으킨다.

Entities 컴포넌트를 테스트할 때 Authorizer와 Interactors까지도 반드시 빌드하고 통합해야 한다.

`Entities, Authorizer, Interactors는 사실상 하나의 거대 한 컴포넌트가 되어 버린다.`

순환 끊기

1. DIP를 적용한다

2. Entities와 Authorizer가 모두 의존하는 새로운 컴포넌트를 만든다.

요구사항이 변경되면 컴포넌트 구조도 변경될 수 있다

하향식(top-down) 설계

컴포넌트 구조는 하향식으로 설계될 수 없다.

컴포넌트는 시스템에서 가장 먼저 설계할 수 있는 대상이 아니며, 오히려 시스템이 성장하고 변경될 때 함께 진화한다.

(위의 예제 처럼 컴포넌트의 의존은 시간이 지나면서 변경되기 마련이다)

바로 이러한 이유 때문에 컴포넌트 구조는 프로젝트 초기에 설계할 수 없다.

아직 아무런 클래스도 설계하지 않은 상태에서 컴포넌트 의존성 구조를 설계하려고 시도한다면
시스템에 대한 파악이 되지 않은 상태기 때문에 상당히 큰 실패를 맛볼 수 있다.

• SDP(Stable Dependencies Principle): 안정된 의존성 원칙

  안정성의 방향으로(더 안정된 쪽에) 의존하라.

  변경이 쉽지 않은 컴포넌트가 변동이 예상되는 컴포넌트에 의존하게 만들어서는 절대로 안 된다. 모듈을 만들 때는 변경하기 쉽도록 설계했지만, 이 모듈에 누군가가 의존성을 매달아 버리면 모듈을 변경하기 어려워진다. (의존으로 인한 변경 영향 전파) 안정된 의존성 원칙Stable Dependencies Principle, SDP을 준수하면 변경하기 어려운 모듈이 변경하기 쉽게 만들어진 모듈에 의존하지 않도록 만들 수 있다.
  

안정성 stability

소프트웨어 컴포넌트를 변경하기 어렵게 만드는 확실한 방법 하나는 수많은 다른 컴포넌트가 해당 컴포넌트에 의존하게 만드는 것이다.

Stable이 Flexible을 의존하기 때문에 Flexible 컴포넌트를 변경 하기가 어렵게 되었다.

→ DIP를 통해 해결

• SAP(Stable Abstraction Principle): 안정된 추상화 원칙
  

컴포넌트는 안정된 정도만큼만 추상화되어야 한다.

업무 로직, 정책과 관련된 컴포넌트가 최고로 안정된 상태이면서도(I=0) 동시에 변 경에 충분히 대응할 수 있을 정도로 유연하게 만들 수 있을까?
→ 해답은 개방 폐쇄 원칙OCP에서 찾을 수 있다.
OCP에서는 클래스를 수정하지 않고도 확장이 충분히 가능할 정도로 클래스를 유연하게 만들 수 있을 뿐만 아니라 바람직한 방식이라고 말한다.    
안정적인 컴포넌트라면 반드시 인터페이스와 추상 클래스로 구성 되어 쉽게 확장할 수 있어야 한다.
안정된 컴포넌트가 확장이 가능해지면 유 연성을 얻게 되고 아키텍처를 과도하게 제약하지 않게 된다.