Skip to content

[Study Log] Funcamentals of Software Architecture #1 #25

@haonly

Description

@haonly

아키텍쳐 공부하기

(책 읽은거 정리)
소프트웨어 아키텍처 101


Chapter1 서론

  • 소프트웨어 아키텍트의 역할은 방대한 분야를 포괄하며 업무 범위도 계속 넓어지고 있음

  • 아키텍처란 예술과 마찬가지로 콘텍스트로서만 이해할 수 있다는 것. (과거와 현재는 다르다. 시간이 지남에 따라 아키텍처 스타일이 달라진다)

  • 아키텍처 결정, 아키텍처 특성, 설계 원칙, 구조로 구성된 소프트웨어 아키텍처.

    • 아키텍처 특성: 가용성/신뢰성/시험성/보안/탄력성/성능/확장성 등등
    • 구조: 마이크로서비스/레이어드 등등
    • 아키텍처 결정: 시스템을 구축하는 규칙(레이어)
    • 설계 원칙: 시스템 구축에 필요한 가이드라인
  • 아키텍트에 대한 기대치

    1. 아키텍처 결정을 내린다
    2. 아키텍처를 지속적으로 분석한다
    3. 최신 트랜드를 계속 유지한다
    4. 아키텍처 결정의 컴플라이언스를 보장한다
    5. 다양한 기술과 경험에 노출된다
    6. 비즈니스 도메인 지식을 보유한다
    7. 대인 관계 기술이 뛰어나다
    8. 정치를 이해하고 처세를 잘한다.
      (???? 스러운 내용도 있다 근데 잘 생각해 보면 맞는 말이다.)
모든 아키텍처는 알려지지 않은 미지의 것들 때문에 자꾸 되풀이되는데, 애자일은 단지 이것을 인지해서 더 빨리 수행하는 것이다.
  • 프로세스는 아키텍처와 거의 분리되어 있지만 소프트웨어 아키텍처의 속성상 반복적인 프로세스가 잘 맞음

  • 문제 영역마다 적합한 아키텍처 스타일이 있듯이 엔지니어링 프랙티스도 동일한 종류의 공생 관계를 맺음

  • 익스트림 프로그래밍 -> continuous delivery

  • 운영/데브옵스

  • 프로세스

    • 소프트웨어를 구축하는 방법(프로세스)은 사실 소프트웨어 아키텍처(구조)에 별다른 영향을 끼치지 않음
  • 데이터

  • 소프트웨어 아키텍처 법칙

    • 소프트웨어 아키텍처 제 1법칙: 소프트웨어 아키텍처의 모든 것은 다 트레이드오프다.
    • 소프트웨어 아키텍처 제 2법칙: '어떻게'보다 '왜'가 더 중요하다.

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions