• 어떤 문제를 소프트웨어로 해결하려면, 아키텍트는 먼저 시스템 요구사항을 취합하고 그것을 구현하는 데 필요한 다양한 기술을 소프트웨어 개발 프로세스에 따라 정리한다.
• 아키텍트는 도메인 기능과 직접적인 관련이 없는 모든 것들, 즉 아키텍처 특성을 정의, 발견, 분석하는 일을 수행한다.

💡 아키텍처 특성은 다음 세 가지 기준을 충족한다. 다음과 같은 성격의 요구사항을 나타낸다.
    1. 비도메인 설계 고려 사항을 명시한다.
    2. 설계의 구조적 측면에 영향을 미친다.
    3. 애플리케이션 성공에 (절대적으로) 중요하다.

비도메인 설계 고려 사항을 명시한다

• 도메인(비즈니스 로직)과 직접적으로 관련되지 않지만, 시스템의 품질과 성능에 영향을 미치는 기술적 요구사항들
• 예를 들면 확장성, 성능, 보안, 유지보수성, 호환성 등
• 아키텍처 특성은 구현하는 방법, 어떤 선택을 하게 된 이유와 관련된 운영/설계 기준을 명시한다.

설계의 구조적 측면에 영향을 미친다

• 아키텍처 특성을 기술하는 주된 이유는, '이 아키텍처 특성은 어떤 특별한 구조적 요소를 고려해야 하는가?' 하는 설계 고려 사항 때문이다.
• 예를 들어 보안이 중요한 시스템이라면 인증/인가를 위한 구조적 요소가 필요하고, 확장성이 중요하다면 분산 시스템을 고려해야 한다.
• 이러한 구조적 요소들은 시스템의 전반적인 설계에 큰 영향을 미치므로 초기에 신중하게 고려되어야 한다.

애플리케이션 성공에 (절대적으로) 중요하다

• 아키텍처 특성을 한 가지만 늘려도 그만큼 설계 복잡도가 가중된다.
• 가급적 아키텍처 특성을 적게 산정하는 일도 아키텍트의 중요한 책무이다.
• 암묵적 아키텍처 특성은 요구사항 정의서에는 거의 안 나오지만 프로젝트 성공을 위해 꼭 필요한 특성들이다.
• 아키텍트는 분석 단계에서 자신이 문제 영역에 대해 습득한 지식을 최대한 활용하여 아키텍처 특성을 밝혀내야 한다.

트레이드 오프 및 나쁜 것 중에서 제일 나은 아키텍처

• 시스템을 설계하며 모든 아키텍처 특성을 빠짐없이 최상으로 반영하기란 불가능에 가깝다.
• 아키텍트가 내린 결정은 상충되는 여러 문제들이 뒤얽힌 트레이드오프로 귀결되는 경우가 많다.

💡 최고의 아키텍처를 고집하지 말고 나쁜 것중에서 제일 나은 아키텍처를 선택하자

• 아키텍처 특성을 너무 욕심내면 모든 비즈니스 문제를 해결하려고 시도하는 일반적인 솔루션이 되어버린다.
• 그런 아키텍처는 설계하기가 대단히 까다롭기 때문에 실현 가능성이 낮다.
• 아키텍트는 가능한 한 아키텍처 설계를 꾸준히 조금씩 반복해보는 것이 좋다.