> 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/8..md).

# 8. 아키텍처 컴포넌트의 균형을 잡아라

## 가이드라인

* **최상위 수준의 컴포넌트 개수와 상대적 크기를 균형잡는다**
* 컴포넌트 개수가 **9개 정도** (6\~12개 사이) 되도록 소스 코드를 조직화하고 컴포넌트 크기를 대략 균등하게 맞춘다
* 균형잡힌 컴포넌트는 코드를 찾고 **독립적**으로 유지보수하기 좋아 유지보수성이 개선됨

> 캡슐화의 경계를 긋는 일은 소프트웨어 아키텍처에서 아주 중요한 기술이다
>
> -조지 H 페어뱅크스의 \<Just Enough Software Architecture> 중에서

### 1. 필요성

컴포넌트 균형이 잡혀 있어야 유지보수가 편리

적절한 수준을 유지하는 것이 중요

#### 균형이 잘 잡힌 컴포넌트 덕분에 *코드를 찾고 분석*하기가 쉽다

* 컴포넌트의 개수는 9개 정도가 유지보수 가능한 수준

#### 균형이 잘 잡힌 컴포넌트 덕분에 *유지보수 효과를 분리* 할 수 있다

#### 균형이 잘 잡힌 컴포넌트 덕분에 *유지보수 책임을 분담* 할 수 있다

### 2. 적용가이드

* 최상위 수준의 시스템 컴포넌트는 9개가 가장 좋고, 6\~12개 사이로 하는편이 좋다
* 컴포넌트 크기 (소스코드량)은 대체로 비슷하게 맞춤
* 강박관념으로 무조건 9개를 맞추려고하는건 금물. 시스템을 자연스럽게 컴포넌트로 나눠야하며, 그 수준이 9개정도가 적당한 케이스가 많기 때문으로 기준을 잡은것

#### 컴포넌트로 기능을 묶는 기준이 되는 올바른 개념 수준

* 기능을 기준으로
* 기술에 따라 프론트, 백엔드, 인터페이스, 로깅 같은 컴포넌트들로 분류 할 수 있음
* 소프트웨어 아키텍트는 시스템에서 기능을 어떻게 묶어야 할지 올바르게 개념을 정립할 의무가 있음&#x20;

#### 시스템 도메인을 명확히 하고 일관되게 적용하라

* 시스템을 어떻게 컴포넌트로 분류할지 결정한 다음, 일관되게 적용 (공통 컴포넌트 같은..)
* 표준화 하여 따르도록 하고, 개발자 모두는 표준에 맞춰 개발을하고 준수하도록 노력해야함

#### 균형이 제대로 잡히지 않으면, 관심사 분리가 제대로 되지 않음의 반증임 (7장의 내용)