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

가이드라인

• 최상위 수준의 컴포넌트 간 결합도를 낮춘다

• 다른 컴포넌트 모듈에 호출을 받는 형태로 공개된 모듈 내부의 상대적인 코드량을 최소화 한다

• 독립적인 컴포넌트는 따로 유지보수하기가 쉬워서 유지보수성이 개선된다.

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

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

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

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

1.필요성

컴포넌트 느슨하게 결합

• 외부 의존관계가 적음

• 코드 책임이 나뉘어져 있음

• 독립적

• 테스트용이

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

• 내부호출 : 호출하는 모듈 끼리 같은 컴포넌트의 구성 요소. 내부 로직은 감춰짐

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

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

• 들어오는(incoming call) 호출 : 유입된 의존성과 연관된 코드를 고치는 행위?는 잠재적으로 다른 컴포넌트에 큰영향을 끼칠수 있음. 유입된 컴포넌트의 변경은 가급적 하지 말아야한다.

• 스루풋(떠넘김) 코드 : 위험성이 높아 반드시 삼가해야하는 코드. 흔히.. 바이패스코드 들어오는 호출을 접수해서 다른 컴포넌트에 위임하며 정보를 감추기는 커녕 위임한코드(구현부)를 호출자에게 노출시킴.

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

• 컴포넌트 코드 상당수가, 내부호출 or 나가는(outcoming) 호출이어야 가능

• 수정한 기능 외에 다른 영향이 없기 때문에 작업량이 확 줄어듬

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

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

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

• 컴포넌트에 덜 의존적인 코드(내부호출, 나가는호출이 대부분인 모듈)일수록 테스트하기가 쉽다.

• 내부호출은 기능추적 및 테스트가 가능

• 나가는 호출은 다른컴포넌트가 제공하는 기능(해당컴포넌트에서 기능을 다 구현했다면)에 대해 목이나 스텁을 만들지 않아도 됨

2.적용가이드

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

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