> For the complete documentation index, see [llms.txt](https://csi-1.gitbook.io/clean-architecture/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://csi-1.gitbook.io/clean-architecture/6week/byungil.md).

# byungil

## 27장. 크고 작은 모든 서비스들

* 서비스 지향 아키텍처와 마이크로서비스 아키텍처는 최근에 큰 인기를 끌고 있는데, 그 이유는 ㅏㄷ음과 같음
  * 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다. 나중에 보겠지만, 이는 일부만 맞는 말이다.
  * 서비스를 사용하면 개발과 배포 독립성을 지원하는 것처럼 보인다. 나중에 보겠지만, 이 역시도 일부만 맞는 말이다.

### 서비스 아키텍처?

* 먼저 서비스를 사용한다는 것은 본질적으로 아키텍처에 해당하지 않음
* 시스템 아키텍처는 의존성 규칙을 준수하며 고수준의 정책을 저수준의 정책으로부터 분리하는 경계에 의해 정의됨
* 단순히 애플리케이션의 행위를 분리할 뿐인 서비스라면 값비싼 함수 호출에 불과하며, 아키텍처 관점에서 꼭 중요하다고 볼 수 없음
* 아키텍처적으로 중요한 서비스도 있지만, 중요하지 않은 서비스도 존재하는데, 이 장에서 우리가 관심을 갖는 서비스는 전자임

### 야옹이 문제

* 서비스 다이어그램을 살펴보면 이 기능을 구현하려면 이들 서비스 전부를 변경해야 함
  * 의심의 여지 없이 야옹이 배달 기능을 추가하려면 개발과 배포 전략을 모두 신중하게 조정해야 함
  * 다시 말해 이 서비스들은 모두 결합되어 있어서 독립적으로 개발하고, 배포하거나 유지될 수 없음
* 이게 바로 횡단 관심사가 지닌 문제임
  * 모든 소프트웨어 시스템은 서비스 지향이든 아니든 이 문제에 직면하기 마련임
  * 위의 서비스 다이어그램과 같은 종류의 기능적 분해는 새로운 기능이 기능적 행위를 횡단하는 상황에 매우 취약함

## 28장. 테스트 경계

* 테스트는 시스템의 일부이며, 시스템의 나머지 요소가 아키텍처에 관여하는 것과 동등하게 아키텍처에도 관여함
* 어떤 면에서는 정말 평범하게 관여하고, 또 다른 면에서는 상당히 독특하게 관여함

### 테스트를 고려한 설계

* 테스트가 시스템의 설계와 잘 통합되지 않으면 테스트는 깨지기 쉬워지고, 시스템은 뻣뻣해져서 변경하기가 어려워짐
* 시스템에 강하게 결합된 테스트라면 시스템이 변경될 때 함게 변경되어야만 함
  * 시스템 컴포넌트에서 생긴 아주 사소한 변경도, 이와 결합된 수 많은 테스트를 망가뜨릴 수 있음
  * 시스템의 공통 컴포넌트가 변경되면 수백, 수천 개의 테스트가 망가지며, 이는 "깨지기 쉬운 테스트 문제"로 알려져있음
  * 깨지기 쉬운 테스트는 시스템을 뻣뻣하게 만드는 부작용을 낳을 때가 많음
  * 시스템에 가한 간단한 변경이 대량의 테스트 실패로 이어진다면, 개발자는 변경을 하지 않을 것임
* 이를 해결하려면 테스트를 고려해서 설계해야 하며, 소프트웨어 설계의 첫 번째 규칙은 언제나 변동성이 있는 것에 의존하지 않는 것
* GUI는 변동성이 크므로 시스템과 테스트를 설계할 때 GUI를 사용하지 않고 업무 규칙을 테스트할 수 있게 해야 함

### 테스팅 API

* 모든 클래스에 테스트 클래스가 각각 존재하고, 또 모든 메소드에 테스트 메소드 집합이 존재하는 테스트 스위트는 강하게 결합됨
* 클래스나 메소드 중 하나라도 변경되면 딸린 다수의 테스트가 변경되어야 함
* 결과적으로 테스트는 깨지기 쉬워지고, 이로 인해 상용 코드를 뻣뻣하게 만듬
* 구조적 결합이 강하면 필수적인 진화 과정을 방해할 뿐만 아니라, 상용 코드의 범용성과 유연성이 충분히 좋아지지 못함

### 결론

* 테스트는 시스템 외부에 있지 않고 시스템의 일부이므로, 테스트를 통한 안정성과 회귀의 이점을 얻으려면 잘 설계 되어야 함
* 테스트를 시스템의 일부로 설계하지 않으면, 테스트는 깨지기 쉽고 유지보수가 어려워지는 경향이 있음
* 이러한 테스트는 유지보수하기 너무 힘들기 때문에 방바닥의 휴지처럼 버려지는 최후를 맡게 됨

## 29장. 클린 임베디드 아키텍처

* 임베디드 엔지니어가 아닌 엔지니어들도 또한 펌웨어를 작성할 수 있음
* 코드에 SQL을 심어두거나, 개발하는 코드 전반에 플랫폼 의존성을 퍼뜨려 놓는다면 본질적으로 펌웨어를 작성하는 셈임
* 안드로이드 앱 개발자 역시 업무 로직을 안드로이드 API로부터 분리하지 않는다면 펌웨어를 작성하는 셈임

### 앱-ㅌ튜드 테스트

* “먼저 동작하게 만들어라”: 소프트웨어가 동작하지 않는다면 사업은 망한다.
* “그리고 올바르게 만들어라”: 코드를 리팩토링해서 당신을 포함한 나머지 사람들이 이해할 수 있게 만들고, 요구가 변경되거나 요구를 더 잘 이해하게 되었을 때 코드를 개선할 수 있게 만들어라.
* “그리고 빠르게 만들어라”: 코드를 리팩토링해서 “요구되는” 성능을 만족시켜라