아키텍처 바이블
회사 프로젝트의 아키텍처를 바꾸기 위해 읽은 첫번째 책이다.
1. 패러다임
패러다임은 프래그래머에게 권한을 부여하는 대신 부정적인 의도를 가지는 일종의 추가적인 규칙을 부과한다. 예를 들어 구조적 프로그래밍은 goto 문을, 객체 지향 프로그래밍은 함수 포인터를, 함수형 프로그래밍은 할당문을 프로그래머로부터 앗아간다.
구조적 프로그래밍
데이스크라는 유클리드의 계층구조로 프로그래밍을 정의하려고 했다. 이를 위해 단순한 알고리즘에 대해 기본적인 증명하면서 프로그램을 더 작은 단위로 분해했다. 그는 순차, 분기, 반복을 통해 수학적으로 각 경로가 적절한 결과를 만들어낸다면 증명은 신뢰할 수 있음을 밝혀냈다. 또한 goto 문이 모듈을 재귀적으로 작은 단위로 분해하는 걸 방해한다고 생각하여 goto 문을 배제해야 한다고 주장했으며 이는 현재까지 많은 언어와 패러다임에서 받아들여진다.
구조적 프로그래밍은 프로그래밍을 반증 가능한 단위로 만들어낸다. 그리고 아키텍처 관점에서 기능적 분해를 최고의 실천법 중 하나로 여기는 이유이기도 하다. 즉, 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록 (테스트하기 쉽도록) 만들어야 한다.
객체 지향 프로그래밍
객체 지향 프로그래밍의 특징은 상속, 캡슐화, 다형성이 있다. 이 중에서 언어 차원에서 확실하게 보장하는 건 다형성이다. 객체지향 프로그래밍에서 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득할 수 있다. 이를 통해 아키텍트는 플러그인 아키텍처를 구성할 수 있고, 이를 통해 고수준의 정책을 포함하는 모듈은 저수준의 세부사항을 포함하는 모듈에 대해 독립성을 보장할 수 있다.
함수형 프로그래밍
함수형 프로그래맹에서는 가변 변수가 없다. x 와 같은 변수가 한 번 초기화되면 절대로 변하지 않는다. 이러한 설계는 동시성 문제를 발생시키지 않는다. 이를 실행하기 위해 애플리케이션 내부 서비스를 가변 컴포넌트와 불변 컴포넌트로 분리한다. 불변 컴포넌트는 순수한 함수형 방식만 사용되며 다음과 같이 통신한다.
상태 변경은 가변 컴포넌트에서 발생한다. 여기서 발생하는 동시성 문제는 트랜잭션 메모리와 같은 실천법으로 동시 업데이트와 경합 조건 문제로부터 가변 변수를 보호한다.
저장 공간과 처리 능력의 발전으로 "이벤트 소싱"이 가능해진다. 이벤트 소싱이란 상태가 아닌 트랜잭션을 저장하는 전략이다. 상태가 필요해지면 단순히 상태의 시작점부터 모든 트랜잭션을 처리한다. 결과적으로 애플리케이션은 CRUD 가 아니라 그저 CR 만 수행한다. 따라서 변경과 삭제가 없으므로 동시 업데이트 문제 또한 일어나지 않는다.
2. 설계 원칙
SRP 단일 책임 원칙
단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다.
또는
하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다.
SRP 는 서로 다른 액터가 의존하는 코드를 서로 분리하는 것이다.
OCP 개방폐쇄원칙
OCP 는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는 데 있다. 이러한 목표를 달성하기 위해 시스템을 컴포넌트 단위로 분리하고, 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조가 만들어져야 한다.
