Clean Architecture 2/2

5부. 아키텍처

 

구분	내용 및 생각
15장. 아키텍처란?	"소프트웨어 아키텍트는 최고의 프로그래머이며, 앞으로도 계속 프로그래밍 작업을 맡을 뿐 아니라 동시에 나머지 팀원들이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어 준다."   소프트웨어 시스템 아키텍처 - "그 모양은 시스템을 컴포턴트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다." - "그리고 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수 되도록 만들어진다."   "시스템 아키텍처는 시스템의 동작 여부와는 거의 관련이 없다." - 개판인 아키텍처도 동작하게 구현할 수 있다. "좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해준다. 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고 프로그래머의 생산성은 최대화하는 데 있다."   개발: 아키텍처는 쉬운 개발할 수 있도록 만들어야 한다. 배포: 단 한번에 쉽게 배포할 수 있어야 한다. 운영: 아키텍처와 가장 연관이 덜한 부분. 하지만 좋은 아키텍처는 개발자에게 시스템 운영방식을 잘 드러내 준다. 유지보수: 가장 비용이 많이 드는 부분. 시스템을 분리, 격리하면 유지보수에 도움이 된다.   소프트웨어 시스템 = 정책 (policy) + 세부사항 "아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는데 있다."  - 대표적 세부사항들: 데이터베이스 시스템, 웹서버, REST, 의존성 주입 프레임워크   좋은 아키텍트는 "결정되지 않은 사항의 수를 최대화한다." "세부사항을 정책으로부터 신중하게 가려내고, 정책이 세부사항과 결합되지 않도록 엄격하게 분리한다."
16장. 독립성	유스케이스 "장바구니 애플리케이션이 좋은 아키텍처를 갖춘다면, 이 애플리케이션은 장바구니 애플리케이션처럼 보일 것이다. 해당 시스템의 유스케이스는 시스템 구조 자체에서 한눈에 드러날 것이다."   운영 - (운영에 필요한) "이러한 결정은 뛰어난 아키텍트라면 열어두어야 하는 선택사항 중의 하나다."   개발 - 콘웨이의 법칙 "시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다."   배포 "좋은 아키텍처라면 시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야 한다."   "좋은 아키텍처는 선택사항을 열어 둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 한다." "서로 다른 두 유형의 규칙은 각자 다른 속도로, 그리고 다른 이유로 변경될 것이다. 따라서 이들 규칙은 서로 분리하고, 독립적으로 변경할 수 있도록 만들어야 한다." "시스템에서 서로 다른 이유로 변경되는 요소들의 결합을 분리하면 기존 요소에 지장을 주지 않고도 새로운 유스케이스를 계속해서 추가할 수 있게 된다. "   결합 분리 모드는 소스 수준, 배포 수준, 서비스 수준으로 규모별로 나눌 수 있다. "이처럼 컴포넌트가 서비스화 될 가능성이 있다면 나는 컴포넌트 결합을 분리하되 서비스가 되기 직전에 멈추는 방식을 선호한다." - 서비스 끼리의 통신은 네트워크 통신이므로 여로모로 비용이 크다.
17장. 경계: 선 긋기	p사의 슬픈 사례 - GUI, 미들웨어, 데이터베이스 서버들끼리 통신하는 아키텍처를 일찍 채택 - 레코드에 필드 하나만 추가해도 프로토콜 4 개, 프로토콜 핸들러 8개 작성해야 함 - "이 비극은 아키텍트가 너무 이르게 결정을 내림으로써 개발 비용을 엄청나게 가중시킨 사례다."   FitNesse 라는 성공 사례 - 우리만의 웹서버 제작: 실제로 수 년이 지나서야 웹 서버 프레임 워크 적용함. (적용에는 얼마 안걸림) - 데이터베이스 고민말자 - "개발 초기에 우리는 업무 규칙과 데이터베이스 사이에 경계선 (Boundary line) 을 그었다." - "자그마치 18개월이라는 기간 동안 운영할 데이터베이스가 없다는 사실은 스키마와 관련한 문제들, 쿼리 문제들, 데이터베이스 서버 문제들, 패스워드 문제들, 접속 시간과 관련한 문제들, (중략) … 문제가 없었다는 사실을 뜻한다. 또한 테스트를 느리게 만드는 데이터베이스가 없으니 테스트를 더 빨리 돌릴 수 있다는 뜻이기도 했다."   "업무 규칙은 스키마, 쿼리 언어, 또는 데이터베이스와 관련된 나머지 세부사항에 대해 어떤 것도 알아서는 안된다." - 둘 사이에 선을 긋자 "입력과 출력은 중요하지 않다" - 업무 규칙과 입출력 사이에 선을 긋자   플러그인 아키텍처 "선택적이거나 또는 수많은 다양한 형태로 구현될 수 있는 나머지 컴포턴트로부터 핵심적인 업무 규칙은 분리되어 있고, 또한 독립적이다." - 예를 들어, 입출력이나 데이터베이스는 최대한 늦게 선정한다.   "경계는 변경의 축 (axis of change) 이 있는 지점에 그어진다. 경계의 한쪽에 위치한 컴포넌트는 경계 반대편의 컴포넌트와는 다른 속도로, 그리고 다른 이유로 변경된다."   소프트웨어 아키텍트가 경계선 (Boundary line) 을 그리는 법 1) 시스템을 컴포넌트 단위로 분할한다. 2) "컴포넌트 사이의 (의존성) 화살표가 특정 방향, 즉 핵심업무를 향하도록 이들 컴포넌트의 소스를 배치한다." - DIP (Dependency Inversion Principle, 의존성 역전 원칙) 과 SAP (Stable Abstraction Principle, 안정된 추상화 원칙) 을 응용한 것이다. - "의존성 화살표는 저수준 세부사항에서 고수준의 추상화를 향하도록 배치된다."
18장. 경계 해부학	시스템 아키텍처 = 소프트웨어 컴포넌트 + 컴포던트들을 분리하는 경계 "경계는 이러한 변경이 전파되는 것을 막는 방화벽을 구축하고 관리하는 수단으로써 존재한다."   기존의 결합 분리 (=결합을 분리한다)는 함수를 가리키는 포인터를 사용함 객체지향, 그 중에서도 다형성 메커니즘 덕분에 결합 분리가 쉬워졌다. - 동적 다형성을 사용하여 제어흐름과 반대방향으로 의존성 역전   한 덩어리로 된 단일체 (Monolith) 라면 하나의 실행파일이다. 소스 수준 분리 모드   동적 링크 라이브러리는 실제로 별도의 파일이 존재한다. = 물리적으로 드러난 경계 - .NET DLL, 자바 .jar, 루비 Gem, 유닉스의 공유 라이브러리 등등 - 배포 수준 분리 모드 - 각각의 컴포넌트는 단일체 (Monolith) 와 같다.   "모든 스레드가 단 하나의 컴포넌트에 포함될 수도 있고, 여러 컴포넌트에 분산될 수도 있다."   로컬 프로세스 - 최상위 컴포넌트라 생각하자. "로컬 프로세스는 컴포넌트간 의존성을 동적 다형성을 통해 관리하는 저수준 컴포넌트로  구성된다." - 각각 독립된 주소 공간에서 실행된다. - 소켓, 메일박스, 메시지큐 등의 운영체제가 제공하는 기능을 이용하여 프로세스간 통신을 한다. - "저수준 프로세스가 고수준 프로세스의 플러그인이 되도록 만드는 것이 아키텍처 관점의 목표라는 사실을 기억하자."   서비스 - "서비스는 모든 통신이 네트워크를 통해 이뤄진다고 가정한다."
19장. 정책과 수준	"소프트웨어 시스템이란 정책을 기술한 것이다."   "수준 (level) 을 엄밀하게 정의하자면 (해당 컴포넌트와) '입력과 출력까지의 거리'다." "멀리 위치할수록 정책의 수준은 높아진다." 즉, 입력과 출력을 다루는 정책 = 최하위 수준 "소스코드 의존성은 그 수준에 따라 결합되어야 하며, 데이터 흐름을 기준으로 결합되어서는 안된다."   결국은 뭐 하나 바꾼다고 소스코드 여기저기를 뒤적거리거나 그 때문에 사이드 이펙트가 나는게 싫다는 것이다. "단일 책임 원칙 (SRP) 과 공통 폐쇄 원칙 (CCP) 에 따르면 동일한 이유로 동일한 시점에 변경되는 정책은 함께 묶인다." "모든 소스코드의 전송의 방향이 고수준 정책을 향할 수 있도록 정책을 분리했다면 변경의 영향도를 줄일 수 있다." "저수준 컴포넌트가 고수준 컴포넌트에 플러그인 되어야 한다는 관점으로 바라볼 수도 있다.
20장. 업무 규칙	애플리케이션 = 업무 규칙 + 플러그인 "업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다."   엔티티 = 핵심 업무 규칙 + 핵심 업무 데이터 (Entity = Critical Business Rule + Critical Business Data) - 핵심 업무 규칙과 데이터는 본질적으로 결합되어 있다.   (엔티티가 구현된 클래스는) "데이터베이스, 사용자 인터페이스, 서드파티 프레임워크에 대한 고려사항들로 인해 오염되어서는 절대 안된다. 이 클래스는 어떤 시스템에서도 업무를 수행할 수 있으며, 시스템의 표현 형식이나 데이터 저장 방식, 그리고 해당 시스템에서 컴퓨터가 배치되는 방식과도 무관하다. 엔티티는 순전히 업무에 대한 것이며, 이외의 것은 없다."   "유스케이스는 자동화된 시스템이 사용되는 방법을 설명한다." (엔티티 내의 핵심 업무 규칙과는 반대로) "유스케이스는 애플리케이션에 특화된 업무 규칙을 설명한다." "엔티티가 어떻게 춤을 출지를 유스케이스가 제어하는 것이다." "유스케이스는 사용자 인터페이스를 기술하지 않는다."   (상대적으로 엔티티가 고수준, 유스케이스가 저수준이다) "왜냐하면 유스케이스는 단일 애플리케이션에 특화되어 있으며, 따라서 해당 시스템의 입력과 출력에 보다 가깝게 위치하기 때문이다." "유스케이스는 단순한 요청 데이터 구조를 입력으로 받아들이고, 단순한 응답 데이터 구조를 출력으로 반환한다. 이들 데이터 구조는 어떤 것에도 의존하지 않는다."   "엔티티 객체를 가리키는 참조를 요청 및 응답 데이터 구조에 포함하려는 유혹을 받을 수도 있다. 엔티티와 요청/응답 모델은 상당히 많은 데이터를 공유하므로 이러한 방식이 적합해 보일 수도 있다. 하지만 이 유혹을 떨쳐내라!" → 유혹에 빠지면 Single Responsibility Principle, Common Closure Principle 을 위배하게 된다.   "업무 규칙은 사용자 인터페이스나 데이터베이스와 같은 저수준의 관심사로 인해 오염되어서는 안 되며, 원래 그대로의 모습으로 남아 있어야 한다." "업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 한다."   < 이미지 출처: https://www.freecodecamp.org/news/a-quick-introduction-to-clean-architecture-990c014448d2/ >
21장. 소리치는 아키텍처	소리친다는 표현은 아키텍처를 보면 무얼 하는 시스템인지, 유스케이스가 보여야 한다는 것이다. - 음악 스트리밍 제공하는 거구나, 고객 데이터를 기기간 동기화 해주는 거구나, 가까운 지역 사람끼리의 중고거래를 챙겨주는 거구나 하고 말이다.   "(이바) 야콥슨은 스포트웨어 아키텍처는 시스템의 유스케이스를 지원하는 구조라고 지적했다." "소프트웨어 애플리케이션의 아키텍처도 애플리케이션의 유스케이스에 대해 소리쳐야 한다."   "좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에, 프레임워크나 도구, 환경에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 아무런 문제 없이 기술할 수 있다. "   "프레임워크가 아키텍처의 중심을 차지하는 일을 막을 수 있는 전략을 개발하라." "프레임워크를 전혀 준비하지 않더라도 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다."   "당신이 헬스 케어 프로그램을 구축하고 있다면, 새로 들어온 프로그래머가 소스 저장소를 봤을 때 첫 인상은 "오, 헬스 케어 시스템 이군" 이어야만 한다."
22장. 클린 아키텍처	"이들의 목표는 모두 같은데, 바로 관심사의 분리 (Seperation of concerns) 이다."   중요 시스템 아키텍처의 공통 특징 - 프레임워크 독립성, 테스트 용이성, UI 독립성, 데이터베이스 독립성, 모든 외부 에이전시에 대한 독립성   < 이미지 출처: https://www.freecodecamp.org/news/a-quick-introduction-to-clean-architecture-990c014448d2/ > "소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다." "내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다." - 내부원은 외부원에 대해 아무것도 모른다. - 외부원의 데이터 형식을 내부원에서 사용해선 안된다.   "어뎁터는 데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서 데이터베이스나 웹같은 외부 에이전시에게 가장 편리한 형식으로 변환한다."  - 어뎁터는 중간에서 데이터의 형식을 변환해주는 것이다.
23장. 프레젠터와 험블 객체	"험블 객체 패턴은 디자인 패턴으로, 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안되었다." "가장 기본적인 본질은 남기고, 테스트하기 어려운 행위를 모두 험블 객체로 옮긴다. 나머지 모듈에는 험블 객체에 속하지 않은, 테스트하기 쉬운 행위를 모두 옮긴다."   "뷰는 험블 객체이고 테스트하기 어렵다." "따라서 뷰는 보잘것 없다. (humble)"   "테스트 용이성은 좋은 아키텍처가 지녀야 할 속성으로 오랫동안 알려져왔다. (중략) 행위를 테스트하기 쉬운 부분과 테스트하기 어려운 부분으로 분리하면 아키텍처 경계가 정의되기 때문이다." "각 아키텍처 경계마다 경계 가까이 숨어 있는 험블 객체 패턴을 발견할 수 있을 것이다."
24장. 부분적 경계	"아키텍처 경계를 완벽하게 만드는 데는 비용이 많이 든다." - 심지어 익스트림 프로그래밍의 YAGNI (You Aren't Going to Need) 를 위배한다. - 타협점으로 부분적 경계를 고려해보자.   1) 마지막으로 실제로 컴포넌트를 분리하는 것만 안하기 2) 양방향 격리대신 일차원 경계 3) 퍼사드 패턴 (Facade)
25장. 계층과 경계	"이 예제를 가져온 이유는 아키텍처 경계가 어디에나 존재한다는 사실을 보여주기 위함이다."   "첫 조짐이 보이는 시점이 되면, 해당 경계를 구현하는 비용과 무시할 때 감수할 비용을 가늠해 본다. 그리고 결정된 사항을 자주 검토한다. 우리의 목표는 경계의 구현 비용이 그걸 무시해서 생기는 비용보다 적어지는 바로 그 변곡점에서 경계를 구현하는 것이다." - 경계를 만드는건 비용이 들고, YAGNI 를 위반하기도 한다. 따라서 신중해야 하는 것이다.
26장. 메인(Main) 컴포넌트	"메인 컴포넌트는 궁극적인 세부사항으로, 가장 낮은 수준의 정책이다." "메인을 지저분한 컴포넌트 중에서도 가장 지저분한 컴포넌트라고 생각하자." "메인을 애플리케이션의 플러그인이라고 생각하자"
27장. '크고 작은 모든' 서비스들	여기서 말하는 서비스는 누구나 이야기하는 마이크로서비스와 같은 의미로 보면 된다. 고객관리 서버, 웹서버, 제품관리 서버 같은게 따로 존재하며 서비스하는 것이다. 이들 서비스 간에는 보통 네트워크를 이용해 통신한다. - 중요한 것은 이렇게 확연히 경계처럼 보이는 서비스 사이가 무조건 경계는 아니라는 것이다.     "지금까지 배운 것은 아키텍처 경계가 서비스 사이에 있지 않다는 사실이다." "아키텍처 경계를 정의하는 것은 서비스 내에 위치한 컴포넌트다." "서비스는 시스템의 확장성과 개발 가능성 측면에서 유용하지만, 그 자체로는 아키텍처적으로 그리 중요한 요소는 아니다."
28장. 테스트 경계	"테스트는 세부적이며 구체적인 것으로, 의존성은 항상 테스트 대상이 되는 코드를 향한다." "변동성이 있는 것에 의존하지 말라." Fragile Test Problem "테스트는 시스템 외부에 있지 않다. 오히려 시스템의 일부다."
29장. 클린 임베디드 아키텍처	"저장되는 위치가 펌웨어를 정의하지는 않는다. 이보다는 무엇에 의존하는지, 그리고 하드웨어 발전에 맞춰 수정하기가 얼마나 어려운지에 따라 정의된다."   1) "먼저 동작하게 만들어라." - 일단 동작은 해야지! 2) "그리고 올바르게 만들어라." - 좋은 아키텍처! 3) "그리고 빠르게 만들어라." - 퍼포먼스를 손볼 시간   세부사항은 소프트웨어 아키텍처에서 중요한 것이 아니다. "하드웨어는 세부사항이다." "프로세서는 세부사항이다." "운영체제는 세부사항이다."

 

 

6부. 세부사항

 

데이터베이스, 웹, 프레임워크와 같은 것들은 세부사항이라는 것이다.

세부사항이라는 말은 소프트웨어 아키텍처에서 중요한 것이 아니라는 것이며, 이것들을 쓸지, 쓴다면 어떤 것을 쓸지에 대한 결정은 가능한 늦추라는 것이다.

 

구분	내용 및 생각
30장. 데이터베이스는 세부사항이다	"어떻게 데이터베이스 시스템이 소프트웨어 시스템과 소프트웨어 기업을 장악할 수 있었을까? (중략) 한마디로 답하자면, 바로 '디스크' 때문이었다." "데이터가 데이터베이스나 파일 시스템에 있더라도, RAM 으로 읽은 후에는 다루기 편리한 형태로 그 구조를 변경한다." - 리스트, 집합, 스택, 큐, 트리 등등 "성능은 시스템의 전반적인 아키텍처와는 아무런 관련이 없다." "데이터는 중요하다. 데이터베이스는 세부사항이다."
31장. 웹은 세부사항이다	"연산 능력을 중앙에 집중하는 방식과 분산하는 방식 사이에서 우리는 끊임없이 움직인다." "IT 역사 전체로 시야를 넓히면 웹은 아무것도 바꾸지 않았다." "GUI는 세부사항이다. 웹은 GUI다. 따라서 웹은 세부사항이다. 그리고 아키텍트라면 이러한 세부사항을 핵심 업무 로직에서 분리된 경계 바깥에 두어야 한다."
32장. 프레임워크는 세부사항이다	프레임워크는 언듯 훌륭하고 잘 만든 기성복을 무료, 혹은 저렴한 가격에  제공하는 것과 같다. 다만 프레임워크는 우리가 구현하려는 시스템을 모르며, 우리가 최대한 자신에게 의존하게 만들려 한다.   "사실상 프레임워크 제작자는 당신에게 프레임워크와 혼인하기를 요구하는 것이다. (중략) 이 혼인 관계는 일방적이다." "프레임워크와 결혼하지 말라!"
33장. 사례 연구: 비디오 판매	생략
34장. 빠져 있는 장	생략

 

 

7부. 부록 A 아키텍처 고고학

 

로버트 C 마틴의 커리어 회고.

많은 실패와 시행착오를 통해 클린 코드, 클린 아키텍처의 원칙들이 나왔다는 것을 알 수 있다.

그냥 읽어 넘겨도 되지만, 깨달음을 얻었다는 부분들을 옮겨적어 본다.

 

내용 및 생각

"의존성을 역전시킬 수 있었던 다형적 인터페이스는 단순히 다음과 같았다. 오버레이 영역에서 모든 애플리케이션을 정확히 같은 메모리 주소로 이동시킴으로써 애플리케이션을 구동시켰다. 이 경계에서는 애플리케이션의 메모리 시작점 외에는 애플리케이션에 대해서 어떤 것도 감독관 프로그램이 알지 못하도록 만들었다." 345P → 즉, 감독관 프로그램이라는 고수준 프로그램이 애플리케이션에 대해 최소한만을 알도록 만들어 두었다는 것. 다만 이때는 클린 아키텍처 개념을 적용하였다기 보다는 우연히 이렇게 되었다.

"이 시스템 내부의 경계는 어떻게 해도 분명해지지 않았다. 심지어 시스템 코드와 DSL로 작성된 애플리케이션 사이의 경계조차 제대로 강제되지 않았다. 모든 곳에 결합이 존재했다. 하지만 1970년대 초반의 소프트웨어는 대체로 이런 모습이었다." 349P

"해결책은 전화를 걸고 회선을 측정하는 소프트웨어 요소와 결과를 분석하고 출력하는 요소를 분리하는 것이었다." 351P "그 경계는 매우 분명했고, 결합 역시 매우 잘 분리되었다." 352P → 결합(의) 분리!

문제점: "왜 우리는 30개의 칩을 모두 교체해야만 했을까? (중략) 결국 아무리 사소한 변경이라도 모든 칩이 영향을 받았다." 354P 해결: "우리는 칩이 배포 독립성을 가지도록 만든 것이다. 다형적 디스패치 (morphic dispatch) 를 발명했고, 객체를 발명했다." 355P → 플러그인 아키텍처

(엄청나게 결합된, 개판인 코드를 수정하다 수정하다 포기한 다음) "이 경험은 내게 훌륭한, 클린 코드의 가치를 깊이 새겨주었다." 357P

"하지만 새로운 모뎀을 받았을 때 그 제어 구조는 완전히 다른 모습이었다. 조금 다른 것이 아니었다. 완전히, 완벽하게 다른 것이었다. 하드웨어 엔지니어야 고맙다." 358P "이러한 낭패를 겪은 덕에 나는 하드웨어를 업무 규칙에서 격리하는 일의 가치, 그리고 인터페이스를 추상화 하는 일의 가치를 배웠다." 358P

"물론 최종적으로는 두 아키텍처 모두 잘 동작했다. 그리고 그 후에 나는 소프트웨어 아키텍처가 완전히 다를지라도 효과는 동등할 수 있다는 사실을 받아들이게 되었다." 368P → 소프트웨어 아키텍처는 동작을 더 잘하게 만드는 것이라기 보다는 다른 것에 더 큰 가치가 있다는 이야기로 보인다. → 개발, 배포, 유지보수 등등 말이다!

"유니파이 (데이터베이스)에 너무 강하게 결합되어 있었기에, 현실적인 비용 범위 내에서 코드 구조를 뜯어고칠 수 있을 거라는 희망을 일절 할 수 없게 되었다." 371P "이 경험은 데이터베이스는 세부사항이며, 시스템의 전반적인 업무목적과는 반드시 분리해야 한다는 원칙을 배울 수 있었던 여러 경험 중 하나였다." 371P

"이 시스템은 진짜 경계가 있다는 표시를 분명하게 보여주었다. 서비스는 독립적으로 배포할 수 있었으며, 자신이 채임지는 도메인 내에서 동작했다. 고수준의 프로세스와 저수준의 프로세스가 있었고, 의존성의 많은 부분이 올바른 방향을 향했다." 373P

"이처럼 상태 머신을 외부적으로 표현함으로써 코드를 변경하지 않고도 애플리케이션의 흐름을 변경할 수 있었다. (개방 폐쇄 원칙, OCP)" 375P

"이 데이터베이스가 우리가 저지른 유일한 실수는 아니었다. 사실 가장 큰 실수는 과도한 아키텍처였다. 이 책에서 설명한 계층보다 훨씬 많은 계층이 있었고, 각 계층은 자신만의 독특한 통신오버헤드를 발생시켰다. 이로 인해 팀 생산성은 급격하게 떨어졌다." 383P "이를 통해 나는 아키텍처가 뛰어나더라도 커다란 실패로 끝날 때도 있다는 사실을 배웠다. 아키텍처는 반드시 문제의 규모에 적합할 정도만큼만 유연해야 한다." 383P

"사용할 수 있는 프레임워크를 먼저 완성해야 비로소 재사용 가능한 프레임워크를 만들 수 있다. 재사용 가능한 프레임워크는 재사용할 다수의 애플리케이션과 맞물려 개발해야만 가능해진다." 386P

 

 

다시 한 번 전체를 정리해보자

 

소프트웨어 아키텍처는 세월이 가도 변치 않는 보편적인 원리들이 있다.

눈부시게 변화하는 하드웨어와는 다르다. 책에 소개된 대표적인 원리들은 아래와 같다.

 

- SOLID (SRP, OCP, LSP, ISP, DIP)

- REP, CCP, CRP

- ADP, SDP, SAP

 

소프트웨어 아키텍처의 목표는 적은 인원으로 개발, 배포, 유지 보수가 쉬운 시스템을 만드는 것이다.

예를 들어, 구조체에 필드 하나를 추가한다고 할때에, 관련한 코드가 가까운데 모여있고, 그거 변경한다고 바뀌어야 하는 코드가 적다면 변경이 쉬울 것이다.

→ 따라서, 필요 인력도 적을 것이다.