기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
FAQ
ADR 프로세스를 생성하면 어떤 이점이 있나요?
프로젝트 팀은 아키텍처 결정을 간소화하고, 동일한 아키텍처 주제에 대해 반복되는 토론을 방지하고, 아키텍처 결정을 효과적으로 전달하기 위한 ADR 프로세스를 생성해야 합니다.
프로젝트 팀은 언제 ADR을 생성해야 하나요?
프로젝트 팀은 구조(마이크로서비스와 같은 패턴), 비기능적 요구 사항(보안, 고가용성, 내결함성), 종속성(구성 요소 결합), 인터페이스(API 및 게시된 계약), 구성 기법(라이브러리, 프레임워크, 도구, 프로세스)에 영향을 미치는 소프트웨어의 모든 측면에 대해 ADR을 생성해야 합니다.
프로젝트 팀은 얼마나 자주 ADR을 검토해야 하나요?
프로젝트 팀은 ADR을 수락하기 전에 한 번 이상 ADR을 검토해야 합니다.
누가 ADR을 생성해야 하나요?
모든 팀원이 ADR을 생성할 수 있습니다. ADR에 대한 소유권 개념을 홍보하는 것이 좋습니다. ADR을 소유한 작성자는 ADR 콘텐츠를 적극적으로 유지 관리하고 전달해야 합니다. 다른 팀원들은 언제든지 ADR에 기여할 수 있습니다. ADR 소유자가 ADR 변경을 승인해야 합니다.
ADR에는 어떤 정보가 포함되어야 하나요?
최소한 각 ADR은 결정의 컨텍스트, 결정 자체, 프로젝트 및 결과물에 대한 결정의 결과를 정의해야 합니다. 컨텍스트에는 팀이 고려했던 가능한 해결책이 언급되어야 합니다. 또한 프로젝트, 고객 또는 기술 스택과 관련된 모든 정보도 포함되어야 합니다. 의사결정에는 팀이 채택하기로 결정한 솔루션이 명령형 언어로 명확하게 명시되어야 합니다. '해야 합니다'와 같은 표현을 사용하지 말고 각 의사결정에 '우리는...사용합니다' 또는 '팀은...사용해야 합니다'라고 표현합니다. 결과 섹션에는 의사결정의 장단점이 모두 언급되어야 합니다. 각 ADR에는 변경 날짜와 변경 책임자가 포함된 상태 및 변경 로그가 있어야 합니다.
ADR 템플릿은 어디에서 찾을 수 있나요?
사용 가능한 ADR 템플릿에는 여러 버전과 변형이 있습니다. 일반적으로 사용되는 ADR 템플릿의 공개 컬렉션은 ADR GitHub 리포지토리
