ch04_mono.md

4.아키텍처 특성 정의

어떤 문제를 소프트웨어로 해결하려면 아키텍트는 먼저 시스템 요구사항을 취합하고 그것을 구현하는 데 필요한 다양한 기술을 소프트웨어 개발 프로세스에 따라 정리합니다.

소프트웨어 아키텍처와 코딩, 설계는 어떤 차이점이 있을까요? 아키텍처 특성을 정의 하는 아키텍트의 역할부터 문제 영역 및 독립적인 시스템의 중요한 부분까지 많은 점들이 다 릅니다.

흔히 말하는 비기능적 ( 코딩 안하는 ) 기능들도 고려해야한다.

비기능적 → 아키텍트적 특성이라고 정의하는 것을 더 도와서 그렇게 치면 아키텍트 적인 특성은 무엇이 있을까 ?

• 비도메인nondomain 설계 고려 사항을 명시한다.
  • 애플리케이션 설계 시 애플리케이션으로 처리할 일은 구체적인 요구사항으로 정리합니다.
• 설계의 구조적 측면에 영향을 미친다.
  • 프로젝트 담당 아키텍트가 아키텍처 특성을 기술하는 주된 이유는, ‘이 아키텍처 특성은 어떤 특별한 구조적 요소를 고려해야 하는가?’ 하는 설계 고려 사항 때문입니다
• 애플리케이션 성공에 （절대적으로） 중요하다.
  • 애플리케이션이 무수히 많은 아키텍처 특성을 전부 다 지원할 수도 있겠지만… 사실 그러면 안됩니다. 지원하는 아키텍처 특성을 한 가지만 늘려도 그만큼 설계 복잡도는 가중되니까요. 가급적 아키텍처 특성을 적게 선정하는 일도 아키텍트의 중요한 책무입니다

멘트가 좋아서 그대로 가져왔습니다.

소프트웨어 아키텍처는 모호한 것들 투성이다

소프트웨어 아키텍처 자체의 활동을 비롯해서 대부분의 중요한 내용이 명확히 정의되어 있지 않
다는 사실에 많은 아키텍트가 끊임 없는 좌절감에 빠지곤 합니다! 그래서 어떤 회사는 스스로 공
통적인 용어를 스스로 정의해서 사용하기도 하지만, 의미가 불확실한 용어를 사용하거나 설상가
상으로 동일한 용어를 다양한 의미로 사용하기 때문에 업계 전체적으로도 혼란스럽습니다. 소프
트웨어 개발 세상에 표준 용어 사전 같은 게 있으면 참좋겠지만 설령 있다고 해도 그것을 강요
할 권리는 없습니다. 그러나 우리는 여러분이 도메인 주도 설계 분야의 조언을 따르고 실천하길
권장하며, 동료들끼리 용어 때문에 오해하는 일이 없도록 서로 보편적인 언어를 정해서 사용하
시기 바랍니다

아키텍처 특성(일부)목록

운영 아키텍처 특성

• 가용성 : 시스템이 얼마나 오랫동안 사용가능 해야하나?
• 연속성 : 재해 복구 능력
• 성능 : 스트레스 테스트, 피크 분석 기능의 사용 빈도 분석필요 용량, 응답 시간.
• 복구성 : 비즈니스 연속성 요구사항(예를 들어, 장애 발생 시 얼마나 신속하게 시스템을 재 가동시켜야 하나?). 백업 전략과 하드웨어 다중화 요건에 영향을 미친다.
• 신뢰성/안전 : 시스템에 페일 세이프가 필요한가? 즉, 페일 세이프가 시스템 가동에 필수 인가? 시스템 실패 시 회사에 거액의 손실이 발생하는가?
• 견고성 : 프로그램 실행 중 인터넷 접속 끊김, 정전, 하드웨어 실패 등 에러 및 경계 조건을 감당하는 능력
• 확장성 : 유저 수, 요청 수가 늘어나도 시스템이 그에 맞는 성능을 발휘하는 능력

견고성 보니깐 떠오른 건데, 만약에 여러분이 데이터 센터를 관리하는데 그곳이 핵폭탄이 맞으면 어떻게 할것 인가요 ??

구조 아키텍처 특성

• 설정성 : 최종 유저가 (쓰기 편한 인터페이스를 통해) 소프트웨어 설정을 쉽게 바꿀 수 있는가?
• 신장성 : 새로운 기능을 삽입하는 일의 중요성
• 설치성 : 필요한 모든 플랫폼에 시스템을 얼마나 손쉽게 설치할 수 있나?
• 활용성/재사용 : 공통 컴포넌트를 여러 제품에서 활용할 수 있나?
• 지역성 : 데이터를 입력/조회하는 화면에서 다국어가 지원되는가?
• 유시보수성 : 시스템을 얼마나 쉽게 변경/개선할 수 있나?
• 이식성 : 하나 이상의 플랫폼에서 시스템을 실행할 수 있나?
• 지원성 : 애플리케이션은 어느 정도의 기술 지원을 필요로 하나? 시스템에서 발생한 에러를 디버깅하려면 로깅 및 기타 기능이 어느 수준으로 뒷받침되어야 하나?
• 업그레이드성 : 이 애플리케이션/솔루션의 구 버전을 새 버전으로 쉽고 빠르게 업그레이드할 수 있는가?

아키텍처 공통 특성

• 접근성 : 색맹, 청각 장애인 등 모든 유저가 접근하는 데 불편함이 없나?
• 보관성 : 데이터를 따로 아카이빙해야 하나, 아니면 일정 시간 경과 후 삭제해야 하나?
• 인증 : 유저가 본인이 맞다는 것을 증명하기 위해 필요한 보안 요구사항
• 인가 : 유저가 애플리 케이션에서 정해진 기능만 사용할 수 있도록 강제하는 보안 요구사항
• 합법성 : 시스템 운영상 법적 제약조건이 있는가?
• 프라이버시 : 회사 내부 임직원의 트랜잭션을 외부에 드러내지 않는 기능(가령, 암호화 트랜잭션 은 DBA나 네트워크 아키텍트도 해독이 불가)
• 보안 : 데이터를 암호화한 후 데이터베이스에 보관해야 하나? 내부 시스템 간 네트워크 통신도 암호화해야 하나? 원격 유저 액세스는 어떤 종류의 인증이 필요한가?
• 사용성/성취성 : 유저가 애플리케이션/솔루션을 이용하여 원하는 목적을 달성하기 위해 필요한 교육/훈련 수준. 사용성 요구사항 역시 다른 아키텍처 이슈 못지않게 진지하게 다루어야 한다.

국제 표준 기구

• 성능 효율 : 알려진 조건에서 리소스 양에 비례하는 성능 측정값.
• 호환성 : 제품, 시스템, 컴포넌트가 다른 제품, 시스템, 컴포넌트와 정보를 교환하고(하거나) 동일한 하 드웨어/소프트웨어 환경을 공유하면서 필요한 기능을 수행할 수 있는 정도.
• 사용성 : 유저가 시스템을 원하는 목적에 맞게 효과적으로, 효율적으로, 만족스럽게 사용할 수 있는 정도.
• 신뢰성 : 주어진 기간 동안 특정 조건에서 시스템이 기능하는 정도.
• 보안 : 사람들, 다른 제품, 시스템이 자신의 인증 레벨에 맞게 데이터를 액세스할 수 있게끔 소프트웨 어가 정보를 보호하는 정도.
• 유시보수성 : 개발자가 얼마나 효율적으로 소프트웨어를 고쳐 개선/발전시키고 계속 변화하는 환경이나 요 구사항에 맞게 적용할 수 있는가를 나타냅니다.
• 이식성 : 개발자가 하드웨어, 소프트웨어, 또는 다른 운용 환경에 있는 시스템, 제품, 컴포넌트를 다른 곳에 옮길 수 있는 정도
• 기능 적합성 : 주어진 조건에서 제품이나 시스템을 가동할 때 명시/암묵적인 요구사항을 충족하는 정도

아키텍처 특성은 어떻게 나열해도 불완전한 목록이 될 수밖에 없고, 소프트웨어마다 고유한 팩 터를 바탕으로 중요한 아키텍처 특성이 도출될 수도 있습니다.

한마디로 체크리스트를 만드려고 해도 매번 매번 다르다고 볼 수 있다. 그러면 우리는 표준이 왜 필요할까 라고 생각해보면서 공통으로 나온다고 느껴지는 것들을 개발자 입장에서 생각해본다면

• 프로그램이 계속 잘 돌아가는가 ??
• 사람들이 편하게 쓸 수 있는 정도인가 ??
• 어디 옮겨갈 일 있으면 잘 옮겨갈 수 있나 ??
• 계속 개발하기 좋은가 ??
• 개발 외적으로 문제되는 일을 신경쓰고 있는가 ??

그래서 이런 프로그램이 되려면 어떤 조건이 있어야할까 ?

• 일단 모듈화가 엄청 잘 되어 있어야 하고 데이터 보안이 되어야 한다

킹무위키 ㄷㄷ;;

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

( 일단 번역체인거 같은데 뭔소리인가 싶었다. )

• 지금까지 열거한 아키텍처 특성들은 여러 가지 이유로 일부만 애플리케이션에서 지원 가능하다.
• 시스템을 설계하며 모든 아키텍처 특성을 빠짐없이 최상으로 반영하기란 불가능에 가 깝다.
• 아키텍트가 내린 결정은 상충되는 여러 문제들이 뒤얽힌 트레이드오프로 귀결되는 경우가 많습니다.
• 아키텍트는 가능한 한 아키텍처 설계를 꾸준히 조금씩 반복해보는 게 좋다