> 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/1week/byungil.md).

# byungil

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

#### 설계와 아키텍처의 정의

* 아키텍처: 저수준의 세부사항과는 분리된 고수준의 무언가
* 설계: 저수준의 구조 또는 결정사항

### 목표는?

* 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고, 유지보수하는데 투입되는 인력을 최소화하는 것
* 설계 품질을 재는 척도는 고객의 요구를 만족시키는데 드는 비용을 재는 척도와 다를 바 없다.
* 이 비용이 낮을 뿐만 아니라, 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계
* 새로운 기능을 출시할 때마다 비용이 증가하면 나쁜 설계

#### 무엇이 잘못되었나?

* 현대의 개발자들은 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 잊고 있음

### 결론

* 개발 조직이 할 수 있는 최고의 선택지는 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것
* 소프트웨어 아키텍처를 심각하게 고민하려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 함
* 비용은 최소화하고 생산성은 최대화 할 수 있는 설계와 아키텍처를 갖는 시스템을 만드려면, 이러한 아키텍처가 지닌 속성을 알아야 함

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

### 행위

* 프로그래머는 이해관계자를 위해 수익을 창출하거나 비용을 절약하도록 함
* 이해관계자가 기능명세서나 요구사항 문서를 구체화할 수 있도록 도움
* 요구사항을 만족하도록 코드를 작성함

### 아키텍처

* 소프트웨어가 가진 본연의 목적을 추구하려면 부드러워야 함
* 즉, 이해관계자가 기능에 대한 생각을 바꾸면, 변경사항을 간단하고 쉽게 적용할 수 있어야 함
* 이때 드는 어려움은 변경의 범위에 비례해야 하며, 형태와는 관련이 없어야 함

### 더 높은 가치

* 완벽하게 동작하지만 수정이 아예 불가능한 프로그램을 내게 준다면, 이 프로그램은 요구사항이 변경될 때 동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없다. 따라서 이러한 프로그램은 거의 쓸모가 없다.
* 동작은 하지 않지만 변경이 쉬운 프로그램을 내게 준다면, 나는 프로그램이 동작하도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다. 따라서 이러한 프로그램은 앞으로도 계속 유용한 채로 남는다.

### 아키텍처를 위해 투쟁하라

* 아키텍처가 후순위가 되면 시스템 개발 비용은 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해짐
* 이러한 상황이 발생하도록 용납했다면, 이는 결국 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻임