클린아키텍처 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는 사실상 하나의 거대 한 컴포넌트가 되어 버린다.`
순환 끊기
- DIP를 적용한다
- Entities와 Authorizer가 모두 의존하는 새로운 컴포넌트를 만든다.
요구사항이 변경되면 컴포넌트 구조도 변경될 수 있다
하향식(top-down) 설계
컴포넌트 구조는 하향식으로 설계될 수 없다.
컴포넌트는 시스템에서 가장 먼저 설계할 수 있는 대상이 아니며, 오히려 시스템이 성장하고 변경될 때 함께 진화한다.
(위의 예제 처럼 컴포넌트의 의존은 시간이 지나면서 변경되기 마련이다)
바로 이러한 이유 때문에 컴포넌트 구조는 프로젝트 초기에 설계할 수 없다.
아직 아무런 클래스도 설계하지 않은 상태에서 컴포넌트 의존성 구조를 설계하려고 시도한다면
시스템에 대한 파악이 되지 않은 상태기 때문에 상당히 큰 실패를 맛볼 수 있다.
- SDP(Stable Dependencies Principle): 안정된 의존성 원칙
안정성의 방향으로(더 안정된 쪽에) 의존하라.
안정성 stability
소프트웨어 컴포넌트를 변경하기 어렵게 만드는 확실한 방법 하나는 수많은 다른 컴포넌트가 해당 컴포넌트에 의존하게 만드는 것이다.
Stable이 Flexible을 의존하기 때문에 Flexible 컴포넌트를 변경 하기가 어렵게 되었다.
→ DIP를 통해 해결
- SAP(Stable Abstraction Principle): 안정된 추상화 원칙
컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
업무 로직, 정책과 관련된 컴포넌트가 최고로 안정된 상태이면서도(I=0) 동시에 변 경에 충분히 대응할 수 있을 정도로 유연하게 만들 수 있을까?
→ 해답은 개방 폐쇄 원칙OCP에서 찾을 수 있다.
OCP에서는 클래스를 수정하지 않고도 확장이 충분히 가능할 정도로 클래스를 유연하게 만들 수 있을 뿐만 아니라 바람직한 방식이라고 말한다.
안정적인 컴포넌트라면 반드시 인터페이스와 추상 클래스로 구성 되어 쉽게 확장할 수 있어야 한다.
안정된 컴포넌트가 확장이 가능해지면 유 연성을 얻게 되고 아키텍처를 과도하게 제약하지 않게 된다.
Author And Source
이 문제에 관하여(클린아키텍처 3주차), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@mertyn88/클린아키텍처-3주차저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)