#architecture #study #clean_architecture

TIL (Today I Learned)

---

🗓 2023.10.18

오늘 읽은 범위

---

📚 4부 컴포넌트 원칙: 12장 ~ 14장. p.97 ~ p.138

책에서 기억하고 싶은 내용

---

12. 컴포넌트 원칙

컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위.

어플리케이션의 규모가 성장하면서, 어플리케이션 코드 및 관련 종속성 코드를 모두 한 곳에 넣는 종래의 방식으로는 계속해서 메모리 공간을 차지하게 되었고 이는 메모리 공간의 단편화를 초래했다.

이러한 단편화를 해결하기 위해 재배치가 가능한 바이너리 가 화두 되었다.

• 즉, 지능적인 로더를 사용해서 메모리에 재배치할 수 있는 형태의 바이너리가 생성되도록 컴파일러를 수정하자는 아이디어
• 프로그래머는 오직 필요한 함수만을 로드하여 사용할 수 있게 됨

컴파일러는 재배치가 가능한 바이너리 안의 함수 이름을 메타 데이터 형태로 생성하도록 수정 됨.

• 프로그램이 라이브러리 함수를 호출 -> 컴파일러는 라이브러리 함수 이름을 외부 참조로 생성
• 라이브러리 함수를 정의하는 프로그램 -> 컴파일러는 해당 이름을 외부 정의로 생성
• 외부 정의를 로드할 위치가 정해지기만 하면 로더가 외부 참조를 외부 정의에 링크 시킬 수 있음
• -> 링킹 로더

링킹 로더의 등장

• 프로그램을 개별적으로 컴파일하고 로드할 수 있는 단위로 분할 가능하게 됨
• 작은 프로그램에서는 잘 동작했지만, 프로그램이 커지면서 이 링킹 로더가 느려짐

느려진 링킹 로더를 해결하고자 역할이 2개로 분리 됨

• 로드(로더)
  - 완료된 재배치 코드를 로드만 시킴
  - 한번 만들어둔 실행 파일은 언제라도 빠르게 로드 가능
• 링크(링커)
  - 별도의 애플리케이션으로 이 작업을 처리
  - 링크가 완료된 재배치 코드 생성

이렇게 나뉘어도 프로그램이 커지면서 물리적으로 느린 장치를 이용하는 한계를 넘어서지 못 했다...!

• 로드 시간은 빨랐지만, 컴파일 - 링크 구간이 병목 지점 발생

무어의 법칙 이 등장함.

• 기술의 발전으로 메모리는 저렴해지고, 디스크는 작아지고 빨라졌다
• 컴퓨터 속도, 메모리, 집적도가 매 18개월마다 두배로 증가한다는 주장
• 1950 ~ 2000년대까지만 유효
• 1990년대 이후, 프로그램을 성장시키는 속도보다 링크 시간이 줄어드는 속도가 빨라지기 시작함
• 컴퓨터가 빨라지기 시작하면서 다시 링크와 로드를 동시에 처리할 수 있어짐
• 컴포넌트 플러그인 아키텍쳐 가 탄생

13. 컴포넌트 응집도

어떤 클래스를 어느 컴포넌트에 포함시켜야 할까?

컴포넌트 응집도와 관련된 세가지 원칙

REP(Reuse/Release Equivalence Principle): 재사용/릴리스 등가 원칙

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

• 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함
• 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 함

CCP(Common Closure Principle): 공통 폐쇄 원칙

동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라.
서로 다른 시점에 다른 이유로 변경되는 클래스는 다름 컴포넌트로 분리하라.

• SRP(단일 책임 원칙)를 컴포넌트 관점에서 바라본 내용
• 단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안 됨
• 대부분 유지 보수성 > 재사용성
  - 변경이 발생한다면, 변경 모두가 단일 컴포넌트에서 발생하는 것이 낫다
  - 변경된 컴포넌트만 재배포 하면 되기 때문
• 변경될 가능성이 있는 클래스는 모두 한곳으로 묶을 것을 권함
• OCP(개방-폐쇄 원칙) 와도 비슷함 - 클래스가 변경에는 닫혀 있고 확장에는 열려 있어야 함
• 100% 폐쇄는 불가는하므로 전략적으로 폐쇄
  - 동일한 유형의 변경에 대해 닫혀 있는 클래스들을 하나의 컴포넌트로 묶음
  - OCP를 확대 적용

CRP(Common Reuse Principle): 공통 재사용 원칙

컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라.

• 클래스와 모듈을 어느 컴포넌트에 위치시킬지 결정할 때 도움이 되는 원칙
• 같이 재사용되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함해야 한다
• 동일한 컴포넌트로 묶어서는 안되는 클래스가 무엇인지도 생각해야 함
• 어떤 컴포넌트가 다른 컴포넌트를 사용하면 의존성이 발생 함
  - 의존하는 컴포넌트가 있다면 해당 컴포넌트의 모든 클래스에 대해 의좀함을 확실히 인지해야 함
• CRP는 ISP(인터페이스 분리 원칙)의 포괄적인 버전
  - 즉, 필요하지 않는 것에 의존하지 마라

REP: 재사용성을 위한 그룹
CCP: 유지보수성을 위한 그룹
CRP: 불필요한 릴리스를 피하기 위해 분리

시간이 흐름에 따라 프로젝트의 초점이 개발 가능성에서 재사용성으로 바뀌고, 그에 따른 컴포넌트 구성하는 방식에도 변화가 발생한다.

컴포넌트 결합

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

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

• 주 단위 빌드
  - 팀 단위에서 개발을 5일 중 4일 진행하고 1일은 각자가 진행한 작업을 통합하는 방식
  - 프로젝트 단위가 커지면서 통합을 위한 막대한 시간이 들기 시작함
  - 통합 테스트를 수행하기 어려워 지고, 빠른 피드백이 주는 장점을 점점 잃게 됨
• 순환 의존성 제거하기
  - 이러한 문제를 어떻게 해결할까?
  - 개발 환경을 릴리스가 가능한 컴포넌트 단위로 분리하는 것
  - 특정 컴포넌트가 변경되더라도 다른 팀에 영향을 주지 않도록 작업 단위를 분리함
  - 타 팀에서 컴포넌트가 릴리즈가 되면, 우리팀은 이를 사용할지? 기존 버전을 사용하고 추후에 업데이트를 할지 결정하여 작업을 진행할 수 있다
  - 이러한 작업이 성공하려면, 컴포넌트 사이의 의존성 구조를 반드시 관리해야 함
  - 비 순환형 방향 그래프
• 순환 끊기
  - DIP(의존성 역전 원칙)을 적용
  - 모두 의존하는 새로운 컴포넌트를 만들고, 각 컴포넌트가 모두 의존하는 클래스들은 새로운 컴포넌트로 이동 시킴
• 흐트러짐(Jitters)
  - 요구 사항이 변경되면 컴포넌트 구조도 변경될 수 있다

하양식(top-down) 설계

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

SDP: 안정된 의존성 원칙

안정성의 방향으로 의존하라

• 변경이 쉽지 않은 컴포넌트가 변동이 예상되는 컴포넌트에 의존하게 만들어서는 절대로 안됨
  - 한번 의존하게 되면 변동성이 큰 컴포넌트도 결국 변경이 어려워 짐
  - 안정된 의존성 원칙을 준수하면 변경하기 어려운 모듈이 변경하기 쉽게 만들어진 모듈에 의존하지 않도록 만들 수 있음
• 안정성
  - 변경을 만들기 위해 필요한 작업량과 관련 됨
  - 컴포넌트 안쪽으로 들어오는 의존성이 많아지면 상당히 안정적이라 볼 수 있다
  - 사소한 변경이라도 의존하는 모든 컴포넌트를 만족시키면서 변경하려면 상당한 노력이 필요
  - 여러 컴포넌트가 하나의 컴포넌트에 의존하면, 의존 대상의 컴포넌트는 변경하지 말아야 한다
  - 이 경우 의존 대상 컴포넌트는 다른 여러 컴포넌트를 책임진다
  - 반대로 의존 대상 컴포넌트는 어디에도 의존하지 않으므로 독립적이다
  - 어떤 한 컴포넌트가 다른 여러 컴포넌트를 의존한다면, 해당 컴포넌트는 책임성이 없다고 할 수 있다.
  - 다만, 의존하는 컴포넌트의 수에 따라 변경이 발생할 수 있는 요인이 많아진다.
  - 이 경우는 의존적이다
• 안정성 지표
  - 컴포넌트 안정성을 측정할 수 있을까? -> 컴포넌트로 들어오고 나가는 의존성의 개수를 세어 보는 방법
  - 이 수를 통해 컴포넌트가 위치상(positional) 어느 정도의 안정성을 가지는지 계산 가능
  - Fan-in
  - 안으로 들어오는 의존성
  - 컴포넌트 내부의 클래스에 의존하는 컴포넌트 외부의 클래스 개수
  - Fan-out
  - 바깥으로 나가는 의존성
  - 컴포넌트 외부의 클래스에 의존하는 컴포넌트 내부의 클래스 개수
  - I(불안정성): I = Fan-out / (Fan-in + Fan-out),
  - [0, 1] 사이의 값을 가짐
  - 0일 수록 안정된 컴포넌트 -> 독립적이다
  - 1일 수록 -> 의존적이다
• 모든 컴포넌트가 안정적이어야 하는 것은 아니다
  - 모든 컴포넌트가 최고로 안정적인 시스템이라면 변경이 불가능 함

SAP: 안정화된 추상화 원칙

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

• 시스템에서 자주 변경해서는 안되는 소프트웨어
  - 고수준 아키텍처 or 정책 결정과 관련된 소프트웨어
• 컴포넌트가 최대로 안정된 상태이면서 동시에 변경에 충분히 대응할 수 있을 정도로 유연하게 만들 수 있을까?
  - OCP 원칙을 이용하자
  - 클래스를 수정하지 않고도 확장이 충분히 가능할 정도로 클래스를 유연하게 만들 수 있음
  - 이 원칙을 준수하는 클래스 -> 추성 클래스
• SAP는 안정성과 추상화 정도 사이의 관계를 정의

읽은 소감

---

• 컴포넌트를 구분하는 단위에 대한 감이 잘 오지 않는다.

궁금한 내용 or 잘 이해되지 않는 내용

---