> For the complete documentation index, see [llms.txt](https://ssosso.gitbook.io/study/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ssosso.gitbook.io/study/dev-build-up/undefined/7..md).

# 7. 아키텍처 컴포넌트를 느슨하게 결합하라

## 가이드라인

* **최상위 수준의 컴포넌트 간 결합도를 낮춘다**
* **다른 컴포넌트 모듈에 호출을 받는 형태**로 공개된 모듈 내부의 상대적인 코드량을 최소화 한다
* **독립적인 컴포넌트는 따로 유지보수하기가 쉬워서** 유지보수성이 개선된다.

> 소프트웨어 디자인을 구축하는 방법은 두가지다. **아주 단순하게** 만들어 확실히 결함을 없게 하는 것과 복잡하게 만들어서 눈에 띄는 결함이 보이지 않게 하는 것이다. C.A.R. 호어

좋은 아키텍처 -> 상위수준의 구조 (틀,뼈대) 이해할 수 있음\
컴포넌트 수준의 의존성!!

**컴포넌트**는 시스템의 최상위 수준을 구성하는 요소로 시스템 소프트웨어 아키텍처에 따라 결정되므로 개발 초기부터 그 경계선을 확실히 긋고 출발해야 함. 컴포넌트는 **느슨하게 결합**해야 함. 구현세부를 감춤(캡슐화)으로써 모듈화가 가능. 컴포넌트끼리는 한정된 정보만 공유하도록 설계.

컴포넌트간 느슨한결합 -> 컴포넌트 독립성 그 반대는 컴포넌트 의존성

### 1.필요성

#### 컴포넌트 느슨하게 결합

* 외부 의존관계가 적음
* 코드 책임이 나뉘어져 있음
* 독립적
* 테스트용이

#### 유지보수성에 긍정적인 호출

* 내부호출 : 호출하는 모듈 끼리 같은 컴포넌트의 구성 요소. 내부 로직은 감춰짐
* 나가는 호출(outgoing call) : 다른 컴포넌트에 할 일을 위임하는 형태. 대외적인 의존성이 발생. 분명히 구분되는 관심사를 다른 컴포넌트에 위임하는 것은 일반적으로 바람직함. 위임은 컴포넌트 내부 어디서건 가능하며 특정 모듈 세트로 한정할 필요는 없음

#### 유지보수성에 부정적인 호출

* 들어오는(incoming call) 호출 : 유입된 의존성과 연관된 코드를 고치는 행위?는 잠재적으로 다른 컴포넌트에 큰영향을 끼칠수 있음. 유입된 컴포넌트의 변경은 가급적 하지 말아야한다.
* 스루풋(떠넘김) 코드 : 위험성이 높아 **반드시 삼가해야하는 코드**. 흔히.. 바이패스코드 들어오는 호출을 접수해서 다른 컴포넌트에 위임하며 정보를 감추기는 커녕 위임한코드(구현부)를 호출자에게 노출시킴.

#### 컴포넌트 의존성이 낮아야 분리해서 유지보수 할 수 있다

* 컴포넌트 코드 상당수가, 내부호출 or 나가는(outcoming) 호출이어야 가능
* 수정한 기능 외에 다른 영향이 없기 때문에 작업량이 확 줄어듬

#### 컴포넌트 의존성이 낮아야 유지보수 책임을 분담할 수 있다

* 컴포넌트는 모두 **독립적**이면 분리 수정작업이 가능하기 때문에 유지보수가 쉽다

#### 컴포넌트 의존성이 낮아야 테스트하기 쉽다.

* 컴포넌트에 덜 의존적인 코드(내부호출, 나가는호출이 대부분인 모듈)일수록 테스트하기가 쉽다.
* 내부호출은 기능추적 및 테스트가 가능
* 나가는 호출은 다른컴포넌트가 제공하는 기능(해당컴포넌트에서 기능을 다 구현했다면)에 대해 목이나 스텁을 만들지 않아도 됨

### 2.적용가이드

**컴포넌트간 결합도**를 낮추는게 목표.

#### 컴포넌트 간 요청 및 인터페이스를 구현하는 원칙