설계 목표 설정
→ 시스템 타입 결정
→ 스타일 적용 및 커스터마이즈
→ 서브 시스템의 기능, 인터페이스 동작 작성
→ 아키텍처 설계 검토
2. 시스템 타입 결정 (Determining the System Type)
개발할 시스템의 전반적인 유형을 결정
시스템의 목적과 규모에 따라
웹 기반 시스템, 배치 처리 시스템, 실시간 시스템, 임베디드 시스템 등으로 나눌 수 있음
이 단계에서 어떤 기술 스택과 아키텍처 스타일이 적합할지 큰 그림을 그림
- 예시: "사용자 상호작용이 많은 웹 기반의 대규모 엔터프라이즈 시스템"
3. 아키텍처 스타일 적용 및 커스터마이즈 (Applying and Customizing Architectural Styles)
결정된 시스템 타입과 요구사항에 가장 적합한 아키텍처 스타일(패턴)을 선택하고,
이를 프로젝트의 특성에 맞춰 구체화하고 조정하는 단계
주요 아키텍처 스타일:
- 계층형 아키텍처 (Layered Architecture): 프레젠테이션, 비즈니스 로직, 데이터 접근 계층 등으로 분리
- 클라이언트-서버 아키텍처 (Client-Server Architecture): 클라이언트와 서버가 분리되어 통신
- 마이크로서비스 아키텍처 (Microservices Architecture): 독립적인 작은 서비스들로 구성
- 이벤트 기반 아키텍처 (Event-Driven Architecture): 이벤트 발생에 따라 비동기적으로 동작
- 파이프-필터 아키텍처 (Pipe-Filter Architecture): 데이터 흐름을 파이프와 필터로 처리
- 예시: "확장성과 유지보수성을 고려하여 마이크로서비스 아키텍처를 기본으로 하고,
각 서비스는 계층형 구조를 따른다."
4. 서브 시스템의 기능, 인터페이스 동작 작성 (Defining Subsystem Functionality and Interfaces)
전체 시스템을 논리적인 서브 시스템(또는 모듈, 컴포넌트)으로 분할하고,
각 서브 시스템이 담당할 기능과
다른 서브 시스템과의 인터페이스(상호작용 방식, 데이터 형식 등)를 상세하게 정의하는 단계
이 단계에서 각 서브 시스템의 책임과 역할을 명확히 함
- 예시:
"사용자 관리 서브 시스템: 회원 가입, 로그인, 정보 수정 기능 제공. 인증/인가 서브 시스템과 연동."
"주문 처리 서브 시스템: 상품 주문, 결제 연동, 주문 내역 조회 기능 제공.
재고 관리 서브 시스템, 결제 게이트웨이와 연동."
5. 아키텍처 설계 검토 및 평가 (Reviewing and Evaluating the Architectural Design)
완성된 아키텍처 설계가 초기 목표와 요구사항을 충족하는지,
잠재적인 문제점은 없는지 등을 다각도로 검토하고 평가하는 단계
이해관계자들과의 협의를 통해 피드백을 반영하고, 필요시 설계를 개선
주요 검토 항목:
- 요구사항 충족 여부: 기능적/비기능적 요구사항을 모두 만족하는가?
- 품질 속성: 성능, 신뢰성, 보안, 유지보수성, 확장성 등이 충분히 고려되었는가?
- 실현 가능성: 주어진 예산, 일정, 기술 스택으로 구현 가능한가?
- 위험 분석: 설계에 내재된 위험 요소는 없는가?
- 예시: "아키텍처 검토 회의를 통해 성능 병목 지점 가능성을 식별하고,
비동기 메시징 큐 도입으로 개선 방안을 마련한다."