아키텍처 예외를 책임 소유자와 종료 계획이 있는, 명시적이고 범위가 제한된 일탈 수용으로 다룹니다. 출시 기한은 의사결정의 맥락이지 제약을 우회하는 자동 허가가 아닙니다.
예외가 가능한지 판단하기
위반하는 정확한 원칙이나 표준과 존재 이유를 식별합니다. 발생하는 위험을 수용할 권한이 누구에게 있는지 확인하세요. 일부 제약은 프로젝트에서 협상할 수 없습니다. 승인 가능한 예외가 없다면 범위를 줄이거나 출시 계획을 바꿉니다.
제안한 예외를 최소 하나의 실행 가능한 대안과 비교하세요. 영향받는 시스템, 사용자, 데이터, 예상 실패 방식, 지연의 비즈니스 결과를 문서화합니다. “임시 레거시 통합” 같은 포괄적인 면제는 피합니다.
예시: 임시 파일 교환
출시가 표준 통합 플랫폼을 기다릴 수 없다고 가정해 보세요. 좁게 정의된 예외가 지정된 두 시스템 사이에 하루 한 번 주문 파일 전송을 6주 동안 허용합니다. 관련 없는 다른 파일 피드를 허용하지는 않습니다.
예외 기록에는 다음이 포함됩니다.