• 아키텍처를 구축하거나 기존 아키텍터의 타당성을 검증할 때 제일 먼저 해야 할 일은 아키텍처 특성을 식별하는 것
• 정확하게 식별하기 위해서는 아키텍트는 해당 도메인을 잘 이해하고 있어야 하며, 도메인 이해관계자들과 협력하여 도메인 관점에서 정말 중요한 것들을 결정해야 한다.
• 아키텍트는 적어도 도메인 관심사, 요구사항, 암묵적 지식, 이렇게 세 가지 출처에서 아키텍처 특성을 밝혀낸다.

5.1 도메인 관심사에서 아키텍처 특성 도출

• 아키텍트는 도메인 관심사를 올바르게 해석하여 정확한 아키텍처 특성을 식별해야 한다.
• 도메인의 핵심 목표와 현재 상황을 고려하여 도메인 관심사를 '~성'으로 해석한 후, 그에 따라 정확하고 합리적인 아키텍처 결정을 내려야 한다.
• 아키텍처에서 가장 흔한 안티패턴 중 하나가, 모든 아키텍처 특성을 지원하는 제네릭 아키텍처를 설계하려는 것이다.
• 지원 가능한 아키텍처 특성 하나하나가 전체 시스템 설계를 복잡하게 만드는 요인이기 때문에 너무 많은 아키텍처 특성을 수용하면 너무 복잡해져버린다.
• 아키텍처 특성의 개수에 연연하지 말고 가급적 설계를 단순화하는 게 좋다.

🌝 생각 ) 통일성을 유지하면서 단순함을 유지하는 게 좋은 것 같다.
    - 많은 것들을 시스템 레벨에서 고려하면 오히려 그것을 기반으로 하는 더욱 복잡한 요구사항이 생길 수 있는 것 같고 시스템은 더욱 복잡해질 수 있는 것 같다.
    - 그리고 하나를 고려할 때 그걸로부터 파생될 수 있는 요구사항들을 생각하는 것도 중요하다. 애매한 의사결정은 시스템을 혼란스럽게 만들 수 있는 것 같다.

• 모든 아키텍처 특성의 우선 순위를 만장일치로 의견이 모아지는 경우는 거의 없다.
• 각자 가장 중요한 특성 3개를 뽑으라고 하고, 합의를 이끌어내기 쉽고 가장 중요한 것은 무엇일까 논의하고 트레이드 오프를 분석하여 결정하자.
• 아키텍트와 도메인 이해관계자들이 서로 다른 언어로 말을 한다는 게 문제 (😅 ㅋㅋ)
• 아키텍트는 확장성, 상호운용성, 내고장성, 학습성, 가용성은 운운하는데, 도메인 이해관계자는 인수병합, 고객 만족, 출시 시점, 경쟁 우의를 논하는 식
• 그래서 도메인 관심사를 아키텍처 특성으로 옮겨야 한다.

5.2 요구사항에서 아키텍처 특성 도출

• 요구사항 정의서에 명시된 문장에서 도출한 아키텍처 특성도 있다.
• 예를 들면, 예상 유저 수와 그에 따른 확장 문제는 보통 도메인 관심사에서 빠지지 않는 단골 사항

💡 아키텍트가 도메인 지식에서 도출되는 특성들도 있는데, 이것이 아키텍트가 도메인 지식을 갖고 있으면 이로운 이유이다.