클린 아키텍처

설계와 아키텍처란?

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

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

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

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

To be continued...

Last updated 2 years ago

Was this helpful?

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

소프트웨어가 가진 본연의 목적을 추구하려면, 소프트웨어는 반드시 '부드러워'야 한다. 다시 말해 변경하기 쉬워야 한다.

새로운 요청사항이 발생할 때마다 이를 반영하기는 점점 어려워지는데, 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.

아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다.

따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.

기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 한다. 이것이 내가 고용된 이유이자 책무이기도 하다.

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 불가능해진다.

4장. 구조적 프로그래밍

"테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다."

즉, 프로그램이 잘못되었음을 즘여할 수는 있지만, 프로그램이 맞다고 증명할 수는 없다.

소프트웨어는 과학과 같다. 최선을 다하더라도 올바르지 않음을 증명하는데 실패함으로써 올바름을 보여주기 때문이다.

이렇게 부정확함에 대한 증명은 입증 가능한 프로그램에만 적용할 수 있다.

구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다.

그리고 테스트를 통해 증명 가능한 세부 기능들이 거짓인지를 증명하려고 시도한다.

이렇게 거짓임을 증명하려는 테스트가 실패한다면, 이 기능들은 목표에 부합할 만큼은 충분히 참이라고 여기게 된다.

구조적 프로그래밍은 프로그래밍에서 반증 가능한 단위를 만들어냈고, 또 아키텍처 관점에서는 기능적 분해를 최고의 실천법 중 하나로 여기는 이유이기 때문이다.

가장 작은 기능에서부터 가장 큰 컴포넌트에 이르기까지 모든 수준에서 소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다.

소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 분주히 노력해야 한다.

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

A 컴포넌트에서 발생한 변경으로부터 B 컴포넌트를 보호하려면, 반드시 A 컴포넌트가 B 컴포넌트에 의존해야 한다.(?)

보호의 계층구조는 '수준(level)'이라는 개념을 바탕으로 생성된다.

아키텍트는 기능이 어떻게, 왜, 언제 발생하는지에 따라서 기능을 분리하고, 분리한 기능을 컴포넌트의 계층구조로 조직화한다.

컴포넌트 계층구조를 이와 같이 조직화하면 저수준 컴포넌트에서 발생한 변경으롭퉈 고수준 컴포넌트를 보호할 수 있다.

To be continued...