[Clean Architecture] 2부 벽돌부터 시작하기: 프로그래밍 패러다임

3장 패러다임 개요

1. 구조적 프로그래밍

최초로 적용된 패러다임.

구조적 프로그래밍은 제어 흐름의 직접적인 전환에 대해 규칙을 부과한다.

 

2. 객체 지향 프로그래밍

함수 포인터를 특정 규칙에 따라 사용하는 과정을 통해 필연적으로 다형성이 등장하게 되었다.

객체 지향 프로그래밍은 제어 흐름의 간접적인 전환에 대해 규칙을 부과한다.

 

3. 함수형 프로그래밍

람다 계산법의 기초가 되는 개념은 불변성(immutability)으로 심볼(symbol)의 값이 변경되지 않는다는 개념이다.

이는 함수형 언어에는 할당문이 전혀 없다는 뜻이기도 하다.

함수형 프로그래밍은 할당문에 대해 규칙을 부과한다.

 

각 패러다임은 일종의 추가적인 규칙을 부과한다. 즉, 패러다임은 무엇을 해야 할지를 말하기보다는 무엇을 해서는 안 되는지를 말해준다.

세 가지 패러다임과 아키텍처의 세 가지 큰 관심사(함수, 컴포넌트 분리, 데이터 관리)가 어떻게 서로 연관되는지에 주목하자.

 

4장 구조적 프로그래밍

모든 프로그램은 순차(sequence), 분기(selection), 반복(iteration)이라는 세 가지 구조 만으로 표현할 수 있다.

 

구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게 되었고, 이는 결국 모듈을 기능적으로 분해할 수 있음을 뜻했다. 이렇게 분해한 기능들은 구조적 프로그래밍의 제한된 제어 구조를 이용하여 표현할 수  있다.

 

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

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

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

 

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

 

5장 객체 지향 프로그래밍

1. 캡슐화

데이터와 함수가 응집력 있게 구성된 집단을 서로 구분 짓는 선.

구분선 바깥에서 데이터는 은닉되고, 일부 함수만이 외부에 노출된다.

 

2. 상속

 

3. 다형성

하나의 객체에 여러 가지 타입을 대입할 수 있다는 것.

 

소스 코드 의존성은 소스 코드 사이에 인터페이스를 추가함으로써 의존성 역전(dependency inversion)을 발생시킬 수 있다.

소프트웨어 아키텍트는 다형성을 통해 시스템의 소스 코드 의존성에 대해 방향을 결정할 수 있는 절대적인 권한을 갖는다.

 

6장 함수형 프로그래밍

함수형 언어에서 변수는 변경되지 않는다.

아키텍트는 변수의 가변성을 염려해야 한다. 경합(rece) 조건, 교착상태(deadlock) 조건, 동시 업데이트(concurrent update) 문제가 모두 가변 변수로 인해 발생하기 때문이다.

 

동시성 애플리케이션에서 즉, 다수의 스레드와 프로세스를 사용하는 애플리케이션에서 발생하는 모든 문제는 가변 변수가 없다면 절대 생기지 않는다. 그렇다면 불변성은 정말로 실현 가능할까?

 

1. 가변성의 분리

애플리케이션을 제대로 구조화하려면 변수를 변경하는 컴포넌트와 변경하지 않는 컴포넌트의 분리가 필요하다. 그러기 위해서는 가변 변수들을 보호하는 적절한 수단을 동원해야 한다.

 

2. 이벤트 소싱

이벤트 소싱은 상태가 아닌 트랜잭션을 저장하자는 전략이다. 상태가 필요해지면 단순히 상태의 시작점부터 모든 트랜잭션을 처리한다.

저장 공간과 처리 능력이 충분하면 애플리케이션이 완전한 불변성을 갖도록 만들 수 있고, 따라서 완전한 함수형으로 만들 수 있다.

예로서 소스 코드 버전 관리 시스템이 정확히 이 방식으로 동작한다.