Clean Architecture: Architecture

소프트웨어 시스템의 아키텍처는 그 속의 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어져야 한다. 

이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를 가능한 한 오래 남겨두는 전략을 따라야 한다. 

시스템 아키텍처는 동작 여부와는 관련이 거의 없고, 배포, 유지보수, 계속되는 개발 과정에 영향을 준다. 즉, 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 쉽게 배포하게 해주는 역할을 하며, 궁극적으로 시스템의 수명과 관련된 비용을 최소화하고 프로그래머의 생산성을 최대화하는 것이다. 

개발

시스템 아키텍처는 개발팀이 시스템을 쉽게 개발할 수 있도록 뒷받침해야 한다. 팀 구조가 다르면 아키텍처 관련 결정에서도 차이가 난다. 여러 팀이 시스템을 개발하고 있을 때, 다른 요소를 고려하지 않는다면 이 시스템의 아키텍처는 다섯 개의 컴포넌트로 발전될 가능성이 높다. 이러한 '팀별 단일 컴포넌트' 아키텍처가 시스템 배포, 운영, 유지보수에 최적일 가능성은 거의 없다. 

배포 

소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데에 목표를 두어야 한다. 초기 개발 단계에서는 배포 전략을 거의 고려하지 않기 때문에 개발하기 쉬울지는 몰라도 배포하기는 상당히 어려운 아키텍처가 만들어진다. 

운영 

아키텍처가 시스템 운영에 미치는 영향을 덜 극적이다. 하지만 좋은 소프트웨어 아키텍처는 시스템을 운영하는 데에 필요한 요구도 알려준다. 시스템 아키텍처가 개발자에게 시스템의 운영 방식을 잘 드러내 준다고 할 수 있다. 시스템 아키텍처는 유스케이스, 기능, 시스템의 필수 행위를 일급 엔티티로 격상시키고, 이들 요소가 개발자에게 주요 목표로 인식되도록 해야 한다. 이를 통해 시스템을 이해하기ㅣ쉬워지며, 따라서 개발과 유지보수에 큰 도움이 된다. 

유지보수

유지보수는 소프트웨어 시스템에서 비용이 가장 많이 든다. 유지보수의 큰 비용은 탐사*와 이로 인한 위험부담에 있다. 주의를 기울여 신중히 아키텍처를 만들면 이 비용을 크게 줄일 수 있다. 시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리한다. 

탐사: 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때, 소프트웨어를 파헤쳐서 어디를 고치는 게 최선인지, 그리고 어떤 전략을 쓰는 게 최적일지를 결정할 때 드는 비용

선택사항 열어두기 

소프트웨어는 두 종류의 가치, 즉 행위적 가치와 구조적 가치를 지닌다. 구조적 가치는 소프트웨어를 부드럽게 만드는 것으로 더 중요하다. 소프트웨어는 기계의 행위를 빠르고 쉽게 변경하는 목적을 가지는데, 이 유연성은 시스템의 형태, 컴포넌트의 배치 방식, 컴포넌트가 상호 연결되는 방식에 상당히 크게 의존한다. 소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이, 그리고 가능한 한 오랫동안 열어 두는 것이다. 열어 두어야 할 선택사항이란 중요하지 않은 세부사항이다. 

소프트웨어 시스템은 정책(policy)과 세부사항(detail)로 나뉜다. 정책 요소는 모든 업무 규칙과 업무 절차를 구체화한다. 세부사항은 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소(입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜 등)이지만, 정책이 가진 행위에는 조금도 영향을 미치지 않는다. 

아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는 데에 있다. 이를 통해 세부사항을 결정하는 일은 미루거나 연기할 수 있게 된다. 

세부사항에 몰두하지 않은 채 고수준의 정책을 만들 수 있다면, 이러한 세부사항에 대한 결정을 오랫동안 미루거나 연기할 수 있다. 이러한 결정을 더 오래 참을 수 있다면, 더 많은 정보를 얻을 수 있고, 이를 기초로 제대로 된 결정을 내릴 수 있다.