클린 아키텍처 - 5부 : 아키텍처 (1/3)

15장 아키텍처란?

소프트웨어 시스템의 아키텍처란 시스테을 구축했던 사람이만들어낸 시스템의 형태다. 그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 의사소통하는 방식에 따라 정해진다.

 

시스템 아키텍처는 시스템의 동작 여부와는 거의 관련이 없다.

 

아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화

 

개발

팀이 작다면 모노리틱 시스템을 개발

개발 초기에는 아키텍처 고나련 제약들이 오히려 방해가 된다고 여길 가능성이 높다.

 

배포

소프트웨어 시스템이 사용될 수 있으려면 반드시 배포할 수 있어야 한다.

아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 그 목표를 두어야 한다.

 

운영

운영에서 겪는 대다수의 어려움은 하드웨어를 더 투입해서 해결할 수 있다.

아키텍처가 개발, 배포, 유지보수를 방해하는 아키텍처보다는 비용이 덜 든다는 뜻이다.

좋은 아키텍처는 시스템을 운영하는데 필요한 요구도 알려준다.

 

유지보수

유지보수는 모든 축면에서 봤을 때 소프트웨어 시스템에서 비용이 가장 많이든다.

유지보스의 가장 큰 비용은 탐사와 이로 인한 위험부담이다.

신중하게 아키텍처를 만들면 이 비용을 크게 줄일 수 있다.

의도치 않은 장애가 발생할 위험을 크게 줄일 수 있다.

 

선택사항 열어두기

유연성은 시스템의 형태, 컴포넌트의 배치 방식, 컴포넌트가 상호 연결되는 방식에 상당히 크게 의존한다.

열어 둬야 할 선택사항이란 무엇일까? 그것은 바로 중요하지 않은 세부사항이다.

모든 소프트웨어 시스템은 두 가지 구성요소로 분해할 수 있다.

정책과 세부사항

세부사항을 결정하는 일은 미루거나 연기할 수 있게 된다.

• 데이터베이스 시스템
• 우베 서버
• REST 적용
• 의존성 주입 프레임워크

선택사항을 더 오랫동안 열어 둘 수 있다면 더 많은 실험을 해볼 수 있고 더 많은 것을 시도할 수 있다.

좋은 아키텍트는 결정되지 않은 사항의 수를 최대화한다.

장치 독립성

장치 종속적

장치 독립적

함수로 추상화

개방 폐쇄 원칙이 탄생하는 순간

광고 우편

광고우편회사 템플릿에 관련된 내용

어떤 장치를 사용할지에 대한 결정을 연기시켰다.

 

좋은 아키텍트는 정책이 세부사항과 결합되지 않도록 엄격하게 분리

세부사항에 대한 결정을 가능한 한 오랫동안 머무를 수 있는 방향으로 정책을 설계한다.

 

16장 독립성

좋은 아키텍처는 다음을 지원해야 한다.

• 유스케이스
• 운영
• 개발
• 배포

유스케이스

아키텍처는 반드시 유스케이스를 지원해야 한다.

시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것이다.

 

운영

아키텍처에서 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않는다면, 시간이 지나 운영에 필요한 요구사항이 바뀌더라도스레드, 프로세스, 서비스로 구성된 기술 스펙트럼 사이를 전환하는 일이 훨씬 쉬워질 것이다.

개발

시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다.

아키텍처를 만들려면 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할할 수 있어야 한다.

 

배포

좋은 아키텍처라면 시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야 한다.

 

선택사항 열어놓기

좋은 아키텍처는 선택사항을 열어 둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 한다.

 

계층 결합 분리

아키텍트는 단일 책임 원칙과 공통 폐쇄 원칙을 적용하여, 그 의도의 맥락에 따라서 다른 이유로 변경되는 것들은 분리하고, 동일한 이유로 변경되는 것들은 묶는다.

아키텍트는 이들을 시스템의 나머지 부분으로부터 분리하여 독립적으로 변경할 수 있도록 해야만 한다.

 

유스케이스 결합 분리

시스템의 맨 아래 계층까지 수직으로 내려가며 유스케이스들이 각 계층에서 서로 겹치지 않게 한다.

 

결합 분리 모드

컴포넌트가 단일 프로세서의 동일한주소 공간에 함께 상주하는 형태로 만들어져서는 안 된다. 분리된 컴포넌트는 반드시 독립된 서비스가 되어야 하고, 일종의 네트워크를 통해 서로 통신해야 한다.

 

개발 독립성

기능 팀, 컴포넌트 팀, 계층 팀, 혹은 또 다른 형태의 팀이라도, 계층과 유스케이스의 결합이 분리되는한 시스템의 아키텍처는 그 팀 구조를 뒷받침해줄 것이다.

 

배포 독립성

유스케이스와 계층이 결합이 분리되면 배포 측면에서도 고도의 유연성이 생긴다.

 

중복

진짜 중복

우발적인 중복

자동반사적으로 중복을 제거해버리는 잘못을 저지르는 유혹을 떨쳐내라. 중복이 진짜 중복인지 확인하라.

 

결합 분리 모드(다시)

소스 수준의 분리 : 하나의 모듈이 변하더라도 다른 모듈을 변경하거나 재컴파일하지 않도록 만들 수 있다.

배포 수준 분리 : 결합이 분리된 컴포넌트 독립적으로 배포할 수 있는 단위로 분할되어 있다.

서비스 수준 분리 : 마이크로 서비스

 

서비스 수준 분리는 비용이 많이 들고 결합이큰 단위에서 분리도니다는 문제가 있다.

 

17장 경계: 선 긋기

소프트웨어 아키텍처는 선을 긋는 기술이며 경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다.

효율을 떨어뜨리는 요인은 결합이다. 특히 너무 일찍 내려진 결정에 따른 결합

 

실패 사례 2가지, 성공 사례 1가지

 

어떻게 선을 그을까? 그리고 언제 그을까?

함수 결합을 통해서 우리는 데이터베이스를 인터페이스 뒤로 숨길 수 있다.

데이터베이스에 대한 결정은 연기를 할 수 있으며, 데이터베이스를 결정하기에앞서 업무 규칙을 먼저 작성하고 테스트하는 데 집중할 수 있음을 의미한다.

 

플러그인 아키텍처

사용자 인터페이스는 플러그인 형태로 고려되었기에, 수 많은 종류의 상ㅇ자 인터페이스를 플러기은 형태로 연결할 수 있게 된다.

 

플러그인에 대한 논의

시스템을 플러그인 아키텍처로 배치함으로써 변경이 전파될 수 없는 방화벽을 생성할 수 있다.

단일 책임 원칙에 해당한다.

 

18장 경계 해부학

경계 횡단하기

소스 코드 의존성 관리

 

두려운 단일체

배포 관점에서 볼 때 단일체는 경계가 드러나지 않는다.

다양한 컴포넌트를 개발하고 바이너리로 만드는 과정을 독립적으로 수행할 수 있게 하는일

다형성

가장 단순한 형태의 경계 횡단은 저수준 클라이언트에서 고수준 서비스로 향하는 함수 호출이다.

고수준 클라이언트가 저수준 서비스를 호ㅜㄹ해야 한다면 동적 다형성을 사용하여 제어프름관느 반대 방향으로 의존성을 역전시킬 수 있다.

 

배포형 컴포넌트

아키텍처의 경계가 물리적으로 드러날 수도 있는데 그중 가장 단순한 형태는 동적 링크 라이브러리다.

 

스레드

모든 스레드가 단 하나의 컴포넌트에 포함될 수도 있고, 맣은 컴포넌트에 분산될 수도 있다.

 

로컬 프로세스

로컬 프로세스는 소켓이나 메일박스 메시지 큐와 같이 운영체제에서 제공하는 통신 기능을 이용하여 서로 통신한다.

로컬 프로세스 간 분리 전략은 단일체나 바이너리 컴포넌트의 경우와 동일하다. 소스 코드 의존성의 화살표는 단일체나 바이너리 컴포넌트와 동일한 방향으로 경계를 횡단한다.

 

서비스

통신은 함수 호출에 비해 매우 느리다.

빈번하게 통신하는 일을 피해야 한다.

저수준 서비스는 반드시 고수준 서비스에 '플러그인' 되어야 한다.

 

19장 정책과 수준

소프트웨어 시스템이란 정책을 기술한 것이다.

소프트웨어 아키텍처를 개발하는 기술에는 이러한 정책을 신중하게 분리하고, 정책이 변경되는 양상에 따라 정책을 재편성하는 일도 포함된다.

 

좋은 아키텍처라면 각 컴포넌트를 연결할 때 의존성의 방향이 컴포넌트의 수준을 기반으로 연결되도록 만들어야 한다.

 

수준

수준을 엄밀하게 정의하자면 입력과 출력까지의 거리다. 시스템의 입력과 출력 모두로부터 멀리 위치할수록 정책의 수준은 높아진다.

데이터 흐름과 소스 코드 의존성이 항상 같은 방향을 가리키지는 않는다는 사실이다.

소스 코드 의존성은 그 수준에 따라 결합되어야 하며, 데이터 흐름을 기준으로 결합되어서는 안 된다.

정책을 컴포넌트로 묶는 기준은 정책이 변경되는 방식에 달려있다는 사실을 상기하자.

단일 책임 원칙과 공동 폐쇄 원칙에 따르면 동일한 이유로 동일한 시점에 변경되는 정책은 함께 묶인다.

모든 소스 코드 의존성의 방향이 고수준 정책을 향할 수 있도록 정책을 분리했다면 변경 영향도를 줄일 수 있다.