7-1 아키텍처 설계

아키텍처 설계 시 고려 사항
- 모든 이해관계자 사이의 의사소통 도구로 활용
- 구현에 대한 제약 사항(개발 비용, 기간)을 저으이
- 모든 이해관계자의 품질 요구사항 반영
- 특정 문제 영역에 적합한 소프트웨어의 구성 요소를 표준화하고 패턴화해 재사용하도록 설계

아키텍처의 특징과 기능
- 아키텍처의 기대 효과
  - 소프트웨어의 기본 골격이 만들어져 개발에 참여하는 사람들의 이해의 폭이 넓어지며 구현상의 문제점을 도출
  - 소프트웨어 아키텍처를 기반으로 분할 방법 찾고 구조화를 위한 구체적인 방안 생각

아키텍처의 품질 속성
- 시스템 품질 속성
  - 가용성
    - 하드웨어는 가용성을 높이기 위해 이중화 설계
  - 변경 용이성
    - 변경이 자주 발생하는 SW는 아키텍처를 설계할 때 변경 용이성을 다른 품질 속성보다 우선으로 고려
  - 성능
    - 어떤 알고리즘을 선택하는지가 중요
  - 보안성
    - 승인되지 않은 사용을 차단하고 올바른 사용자에게 서비스가 제공될 수 있게 설계
  - 사용성
    - 시스템의 도움말 기능은 사용자에게 실제 도움을 줄 수 있어야 함
    - 사용자 실수에도 오류의 영향을 최소화
  - 테스트 용이성
    - 테스트 비용을 줄이기 위해서는 아키텍처 설계부터 테스트 고려
- 비즈니스 품질 속성
  - 시장 적시성
    - 적정한 시기에 소프트웨어를 출시해 경쟁력을 높이는 것
  - 비용과 이익
    - 비용 절감에 초점을 두면 우선 개발 비용이 적게 드는 효과, 유지보수를 할 떄 비용 증가
  - 예상 시스템 수명
    - 확장성, 이식성과 같은 아키텍처 품질 속성을 고려
  - 목표 시장
    - 이식성 충분히 고려
- 아키텍처 품질 속성
  - 개념적 무결성
    - 세부 구성 요소를 전체 시스템으로 통합하더라도 일관성 유지
  - 정확성과 완전성
  - 개발 용이성
    - 개발 과정 중에도 쉽게 변경할 수 있는 능력

계층 스타일
- 기능을 몇 개의 계층으로 나누어 배치
- 각 계층의 응집도는 높고 계층 간 결합도는 낮아 재사용 및 유지보수 용이
- 역할 분담 명확

7-2 클래스 설계원칙

SOLID
- 단일 책임 원칙
  - 클래스 변경해야 하는 이유는 한 개
- 개방 폐쇄의 원칙
  - 확장에는 열려 있어야 하고 변경에는 닫혀야 함
- 리스코프 교체의 원칙
  - 기반 클래스는 파생 클래스로 대체
- 인터페이스 분리의 원칙
  - 구체적 여러 개의 인터페이스가 나음
- 의존 관계 역전의 분칙
  - 클라이언트는 추상 클래스에 의존

GoF의 디자인 패턴
- 쉽게 재사용할 수 있도록 객체지향 개념에 따른 설계만을 패턴으로 지정
  - 생성 패턴
    - 객체의 인스턴스 과정을 추상화하는 방법
    - 프로그램에 유연성을 더해줌
    - 추상 팩토리, 빌더, 팩토리 메소드, 프로토타입, 싱글톤
  - 구조 패턴
    - 클래스나 객체를 조합해 더 큰 구조로 만들 수 있게 해주는 패턴
    - 어댑터, 브리지, 컴포지트, 데코레이터, 퍼싸드, 플라이웨이트
  - 행동 패턴
    - 클래스나 객체들이 서로 상호작용하는 방법이나 어떤 태스크, 어던 알고리즘을 어떤 객체에 할당하는 것지 좋은지 정의 패턴
    - 책임 연쇄, 커맨드, 인터프리터, 반복자

아키텍처 패턴 vs 디자인 패턴
- 아키텍처는 디자인보다 상위일 떄 사용
- 아키텍처 : 전체 시스템의 구조를 설계하기 위한 참조 모델
- 디자인 ; 서브시스템에 속하는 컴포넌트들끼리의 관계를 설계하기 위한 참조 모델