소프트웨어 설계 및 아키텍처
소프트웨어 설계 및 아키텍처는 소프트웨어 시스템이 구성 요소와 커넥터로 어떻게 구조화되는지, 책임이 어떻게 분해되는지, 그리고 설계 결정이 기능적 요구 사항과 품질 속성을 어떻게 충족하는지에 관한 것입니다.
Definition
소프트웨어 설계는 시스템의 아키텍처, 구성 요소, 인터페이스 및 기타 특성을 정의하는 과정이며, 소프트웨어 아키텍처는 시스템의 요소, 그 관계, 그리고 둘 모두의 속성을 포함하는 구조의 집합입니다.
Scope
이 영역은 아키텍처 스타일 및 패턴(계층형, 클라이언트-서버, 마이크로서비스, 이벤트 기반, 파이프-필터); 모듈성, 정보 은닉, 응집도, 결합도, 관심사 분리와 같은 설계 원칙; 객체 지향 및 컴포넌트 기반 설계; 디자인 패턴; 아키텍처 품질 속성 및 그 절충; 그리고 설계를 표현하는 데 사용되는 UML과 같은 모델링 표기법을 다룹니다.
Sub-topics
Core questions
- 시스템은 모듈과 구성 요소로 어떻게 분해되어야 하는가?
- 어떤 아키텍처 스타일이 필요한 품질 속성을 가장 잘 지원하는가?
- 결합도와 응집도와 같은 설계 원칙이 좋은 구조를 어떻게 안내하는가?
- 재사용 가능한 패턴으로 반복되는 설계 문제는 어떻게 해결되는가?
Key theories
- 정보 은닉 및 모듈성
- Parnas는 모듈이 변경될 가능성이 있는 설계 결정을 안정적인 인터페이스 뒤에 숨기도록 정의되어야 하며, 이를 통해 변경이 국지화된다고 주장했습니다. 이 원칙은 모듈성, 캡슐화 및 낮은 결합도의 기반이 됩니다.
- 아키텍처 품질 속성 및 절충
- 아키텍처는 성능, 수정 용이성, 가용성, 보안과 같은 품질 속성에 의해 좌우됩니다. 이러한 속성들은 서로 상충하기 때문에, 아키텍처는 본질적으로 전술과 패턴에 의해 안내되는 절충에 대한 추론에 관한 것입니다.
- 디자인 패턴
- 반복되는 설계 문제에는 잘 알려진 명명된 해결책(생성, 구조, 행위 패턴)이 있으며, 이는 전문가의 관행을 포착하고 객체 지향 설계를 위한 공유 어휘를 제공합니다.
Clinical relevance
아키텍처 결정은 나중에 변경하기 가장 어렵고 시스템의 품질 속성을 가장 강력하게 결정하므로, 건전한 설계 및 아키텍처는 장기 유지보수 비용을 절감하고 확장성 및 진화를 가능하게 하며 팀 조직을 형성합니다.
Evidence & guidelines
ISO/IEC/IEEE 42010은 아키텍처 설명을 표준화하며, SWEBOK 소프트웨어 설계 지식 영역은 Software Architecture in Practice와 같은 참고 문헌과 함께 합의된 지침을 제공합니다.
History
모듈식 설계 원칙은 1970년대 초 Parnas에 의해 명확히 제시되었습니다. 객체 지향 설계 및 디자인 패턴은 1980년대와 1990년대에 성숙했으며, 소프트웨어 아키텍처는 1990년대 중반 Shaw와 Garlan의 작업을 통해 독립적인 분야로 부상했고, 서비스 지향 및 마이크로서비스 스타일은 2000년대와 2010년대에 뒤따랐습니다.
Debates
- 모놀리식 대 마이크로서비스 아키텍처
- 시스템을 단일 배포 가능한 모놀리스로 구축할지 또는 여러 독립적으로 배포 가능한 서비스로 구축할지에 대한 논쟁이 광범위하게 이루어지고 있습니다. 마이크로서비스는 분산 시스템 복잡성이라는 대가를 치르면서 독립적인 확장 및 배포를 제공하므로, 올바른 선택은 규모와 조직 구조에 따라 달라집니다.
Key figures
- David Parnas
- Mary Shaw
- Len Bass
- Erich Gamma
- Grady Booch
Related topics
Seminal works
- parnas1972
- gamma1994
- bass2012
Frequently asked questions
- 설계와 아키텍처의 차이점은 무엇인가요?
- 아키텍처는 가장 높은 수준의 구조와 변경 비용이 가장 많이 드는 결정(주요 구성 요소, 그 상호 작용, 시스템 전반의 품질 속성)에 관한 반면, 설계는 이러한 구성 요소의 더 상세한 내부 구조를 다룹니다. 그 경계는 명확한 선이라기보다는 중요성의 차이입니다.
- 디자인 패턴이 왜 중요한가요?
- 패턴은 반복되는 설계 문제에 대한 검증된 해결책을 포착하고 엔지니어에게 공유 어휘를 제공하여 설계를 더 쉽게 소통하고, 추론하며, 발전시킬 수 있도록 합니다. 이는 강제적인 레시피가 아니라 신중하게 적용해야 할 지침입니다.