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

# 클린 아키텍처

## 1장. 설계와 아키텍처란?

* 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다. (p.7)

## 2장. 두 가지 가치에 대한 이야기

* 소프트웨어가 가진 본연의 목적을 추구하려면, 소프트웨어는 반드시 '부드러워'야 한다. 다시 말해 변경하기 쉬워야 한다.
* 새로운 요청사항이 발생할 때마다 이를 반영하기는 점점 어려워지는데, 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.
* 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다.
* 따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.
* 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 한다. 이것이 내가 고용된 이유이자 책무이기도 하다.
* 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 불가능해진다.

## 4장. 구조적 프로그래밍

* "테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다."
* 즉, 프로그램이 잘못되었음을 즘여할 수는 있지만, 프로그램이 맞다고 증명할 수는 없다.
* 소프트웨어는 과학과 같다. 최선을 다하더라도 올바르지 않음을 증명하는데 실패함으로써 올바름을 보여주기 때문이다.
* 이렇게 부정확함에 대한 증명은 입증 가능한 프로그램에만 적용할 수 있다.
* 구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다.
* 그리고 테스트를 통해 증명 가능한 세부 기능들이 거짓인지를 증명하려고 시도한다.
* 이렇게 거짓임을 증명하려는 테스트가 실패한다면, 이 기능들은 목표에 부합할 만큼은 충분히 참이라고 여기게 된다.
* 구조적 프로그래밍은 프로그래밍에서 반증 가능한 단위를 만들어냈고, 또 아키텍처 관점에서는 기능적 분해를 최고의 실천법 중 하나로 여기는 이유이기 때문이다.
* 가장 작은 기능에서부터 가장 큰 컴포넌트에 이르기까지 모든 수준에서 소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다.
* 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 분주히 노력해야 한다.

## 8장. OCP: 개방-폐쇄 원칙

* A 컴포넌트에서 발생한 변경으로부터 B 컴포넌트를 보호하려면, 반드시 A 컴포넌트가 B 컴포넌트에 의존해야 한다.(?)
* 보호의 계층구조는 '수준(level)'이라는 개념을 바탕으로 생성된다.
  * 가장 높은 수준의 개념은, 최고의 보호를 받는다. 반면 가장 낮은 수준의 개념(e.g. View)은 거의 보호를 받지 못한다.
* 아키텍트는 기능이 어떻게, 왜, 언제 발생하는지에 따라서 기능을 분리하고, 분리한 기능을 컴포넌트의 계층구조로 조직화한다.
* 컴포넌트 계층구조를 이와 같이 조직화하면 저수준 컴포넌트에서 발생한 변경으롭퉈 고수준 컴포넌트를 보호할 수 있다.

To be continued...