[3부 코드의 모습] Chapter14 소프트웨어 아키텍처

소프트웨어 아키텍처란?

상위 수준의 설계

 

소프트웨어의 청사진

아키텍처 수준의 관점

1. 핵심이 되는 소프트웨어 모듈들을 식별
2. 어느 컴포넌트가 어느 컴포넌트와 통신하는지 식별
3. 여러 가지 서브시스템의 올바른 역할과 책임을 명시하고, 시스템에 있는 모든 중요한 인터페이스들의 특성을 식별하고 결정하도록 도와준다

우아하게 개발~~ 매번 나오는 이야기

아키텍처는 소프트웨어 시스템의 설계와 미래 성장에 가장 큰 영향력을 미친다. 그러므로 개발 단계에서 일찍 올바른 아키텍처를 만들어두는 것이 극히 중요

조망도(view)

아키텍처를 설계하는 과정에서도 여러 개의 소프트웨어 조망도를 개발해야 한다

개념 조망도

시스템에서 중요한 부분과 그 부분들의 상호연결을 보여주는 조망도

구현 조망도

실제로 구현된 모듈을 가지고 제시

프로세스 조망도

시스템의 동적인 구조를 태스크(task), 프로세스, 통신을 가지고 보여준다

배치 조망도

분산 시스템에서 물리적인 노드에 태스크를 어떻게 할당하는지 보여주기 위해 사용

초기 아키텍처 국면에서의 주요한 결과물은 개념 조망도이다

어디서, 언제 하나?

아키텍처 규격서 같은 어떤 문서 안에 캡쳐된다

무엇에 사용되나?

검증

아키텍처는 구축할 시스템을 처음으로 검증하는 기회

의사소통

아키텍처 규격서는 시스템에 관심이 있는 모든 사람들이 의사소통을 하기 위해 사용할 수 있다

아키텍처 규격서는 시스템의 모양새에 대해서 의사소통하는데 필요한 핵심적인 장치이다

구별

의사 결정에 도움을 받기 위해 아키텍처를 사용한다

컴포넌트와 연결에 대하여

컴포넌트

아키텍처는 컴포넌트 각각에 대한 정보를 캡처한다

연결

아키텍처는 컴포넌트들 사이의 연결을 모두 식별하고, 그 연결의 특성에 대해서 기술한다

 

아키텍트 대 마케터

기술적인 아키텍처를 설계하는 사람은 새로운 소프트웨어가 회사의 전체적인 전략과 얼마나 잘 맞는지, 고객이 정말 비범한 해결책을 얻기 위해 요구하는 것이 무엇인지 알기 위해서 마케팅 의사 결정자와 긴밀하게 협조해야 한다

진정으로 훌륭한 아키텍처는 기술적인 비전과 전략적인 비전이 만나서 경쟁자들 사이에서 돋보이는 제품을 만들었을 때 탄생한다

 

좋은 아키텍처란?

단순성!!!!

아키텍처 수준의 설계에서는 커플링이 낮고 응집력이 높은 모듈을 만드는 것이 목표다

융통성 있는 설계를 위한 메커니즘을 제공한다

좋은 아키텍처는 기동성, 확장성, 수정을 위한 여지를 남겨둔다

 

아키텍처 스타일

아키텍처가 없는 경우

시작도 하기 전에 개발은 파멸로 이르게 됨

계층 아키텍처

개념적인 조망을 할 때 흔히 사용됨

파이프와 필터 아키텍처

시스템을 통과하는 데이터의 논리적인 흐름 - 전 회사에서 주로 사용

클라이언트/서버 아키텍처

전형적인 네트워크 기반의 아키텍처이고, 요구 기능을 주요한 두 개의 조각으로 나눈다; 클라이언트 서버

서버

클라이언트에게 잘 정의된 서비스를 제공

클라이언트

서버의 서비스를 사용

2-티어(tier)아키텍처

컴포넌트 기반의 아키텍처

제어가 집중되지 않도록 분산하고, 시스템을 하나의 덩어리가 아니라 협동 작업을 하는 몇 개의 컴포넌트들로 나눈다

프레임 워크

기존에 있는 애플리케이션의 프레임워크를 가져다가 거기에 개발된 것을 추가하는 것이 적절할 수도 있다

 

좋은 프로그래머는…

자기의 소프트웨어 아키텍처에 대해 알고 있고, 그 안에서 새로운 코드를 작성한다

설계 시나리오 각각에 대해서 적절한 아키텍처를 적용할 수 있다

아름답고 세련된 단순한 아키텍처를 만들어낸다 - 소프트웨어 설계의 아름다움을 올바르게 인식하고 있다

시스템 아키텍처를 캡처해서, 계속 업데이트되고 있는 활성화된 문서 안에 기록한다

시스템 구조에 관한 문제점을 시스템 아키텍트에게 전달해서 설계의 개선에 도움이 되도록 한다

나쁜 프로그래머는…

아키텍처의 전체 비전에 전혀 신경을 쓰지 않으면서 코드를 작성한다 - 그 결과 코드는 다른 부분과 조화를 이루지 못하게 되고, 컴포넌트들은 서로 통합이 되지 않는다

코딩을 시작하기 전에 높은 수준의 설계를 수행하지 않는다. 아키텍처 상에서 선택할 수 있는 대안을 모두 무시한다

아키텍처 수준의 정보를 머리 속에만 둠으로써 아예 접근할 수 없게 만들거나, 위험할 정도로 업데이트가 되지 않는 규격서 안에 둔다

부적절한 아키텍처를 꾹 참고 계속 사용한다. 하부에 깔려 있는 문제점을 고치는 것이 아니라, 거기에 잘못 설계된 코드를 추가한다 - 일이 커지는 것을 귀찮아한다