아키텍처 선택 및 피트니스 체크
목표를 관찰 가능한 동작으로 변환
액터, 중요 워크플로, 데이터 소유권 및 제약 조건을 식별합니다. "확장 가능한", "안전한", "유지보수 가능한"을 자극 → 환경 → 응답 → 측정 시나리오로 변환합니다. 설계를 실질적으로 결정하는 몇 가지 특성에 순위를 매깁니다. 필수 제약 조건과 선호 사항을 구분합니다.
절차
- 이해관계자와 품질 시나리오 및 승인 임계값을 정의합니다. 워크로드, 장애 및 팀 가정을 명시합니다. 선택을 사용합니다.
- 각 속성이 유지되어야 하는 범위(컴포넌트, 배포, 워크플로 또는 전체 시스템)를 식별합니다. 다른 부분은 다른 스타일을 정당화할 수 있습니다.
- 모듈식 단일 배포를 포함하여, 소수의 실현 가능한 스타일을 해당 시나리오와 비교합니다. 각 주장된 이점을 지원하는 메커니즘을 설명합니다.
- 커플링(소스 종속성, 런타임 호출, 공유 데이터 및 조정 변경)을 검토합니다. 정적 모듈 독립성은 런타임 장애 격리를 증명하지 않습니다.
- 가장 단순한 실행 가능한 스타일을 선택하고 ADR, 결과 및 재고 트리거를 기록합니다. 되돌릴 수 있는 구현 세부 사항은 비용이 많이 드는 구조적 약속과 분리합니다.
- 중요한 결정을 피트니스 체크(금지된 종속성, 계약 호환성, 지연 시간 예산, 복원 시간 및 테넌트 격리)로 전환합니다. 피트니스 체크를 사용합니다.
- 관찰된 부하 및 변경 패턴에 따라 재평가합니다. 통과하는 종속성 규칙은 하나의 속성에 대한 증거일 뿐, 전체 아키텍처 품질을 의미하지는 않습니다.
검토 질문
- 플러그인 경계가 모든 플러그인에 코어에 대한 무제한 액세스를 부여하지 않으면서 실제 확장성 요구를 해결합니까?
- 이벤트에 지속적인 게시, 스키마 호환성, 중복 제거 및 지연 모니터링이 필요합니까? 이러한 비용이 이벤트 기반 제안에 포함되어 있습니까?
- 별도 배포가 측정된 병목 현상을 개선하거나 릴리스 제약 조건을 완화합니까?
- 제안된 팀이 결과적인 배포 및 장애 복잡성을 운영할 수 있습니까?
- 데이터 소유권이 분할될 때 어떤 불변성이 더 어려워집니까?
출력
품질 시나리오, 후보 메커니즘/트레이드오프, 선택된 구조, 소유권/종속성 맵, ADR, 피트니스 체크 및 해결되지 않은 가정을 반환합니다.
범위 및 참고 자료
Fundamentals of Software Architecture, 2판(Richards and Ford)에 맞춰 부분적으로 다룹니다. 저자 자료, 공개 저자 인터뷰 기록, 출판사 내용 및 아키텍처 테스트 문서가 이 독창적인 가이드를 뒷받침합니다. 출처를 참조하세요. 어떤 스타일도 보편적인 성숙 단계가 아닙니다.