ADR 작성하기

제목

{둘 또는 세 자리 숫자} : {제목} 상태: {상태값} {, 대체 주석}

예)

001: 설문조사 기능을 위해 RDBMS로 MySQL을 사용 상태: 적용

 

소프트웨어의 규모가 크고 오랫동안 기능 개선 및 유지보수가 된다면 세 자리 숫자를 사용하고, 요구사항이 크지 않거나, 소프트웨어 생명주기가 짧은 프로젝트의 경우 두 자릿수로도 충분하다.

 

상태 

상태	설명	설명
RFC Request for Comment	발의	의견이 발의된 상태 누구든지 ADR에 대한 의견과 비판을 할 수 있다.
Proposed	상정	의견 조율이 끝나고 승인을 요청한 상태 승인을 기다리고 있는 상태임을 의미
Accepted	승인	ADR에 합의된 대로 아키텍처의 구성을 시작할 수 있는 상태
Applied	적용	ADR의 내용이 적용된 상태
Superseded	대체	기존 아키텍처가 새로운 아키텍처로 대체된 상태

 

예)

> 이전 ADR 상태

042: 설문조사를 위해 RDBMS로 MySQL을 사용 상태: 적용

> Proposed 상태 
053: 설문조사 기능에 다양한 설문 방식을 추가하기 위해 몽고DB로 변경 상태: 제안, 042를 대체
기존 아키텍처를 변경하는 경우에는 발의 단계부터 기존 ADR 번호를 명시

> Accepted 상태 

042: 설문조사를 위해 RDBMS로 MySQL을 사용 상태: 적용, 053으로 대체됨

053: 설문조사 기능에 다양한 설문 방식을 추가하기 위해 몽고DB로 변경 상태: 승인, 042를 대체함

 

Tip!

• 대체됨과 대체함을 모두 표시해야 ADR이 많아졌을 때 변경 내역을 인지하기 쉽습니다.
• 이미 적용한 아키텍처의 수정이 필요할 때 과거의 ADR을 수정하면 안됩니다. 새로운 ADR을 작성해서 History를 남겨야 시간의 흐름으로 아키텍처가 어떻게 변경이 되었는지를 알 수 있습니다.
• 예를 들어 최신 ADR이 52번은데 07번 ADR을 수정하면 07번 ADR이 언제 적용되었고, 왜 아키텍처 변경이 발생했는지 알 수 없게 됩니다.

 

맥락

아키텍처의 결정은 맥락과 제약조건 내에서 해야 합니다. 결정에 영향을 미친 모든 요소를 기록해야 합니다. 

 

예)
맥락

설문조사 응답의 방식을 다양하게 (멀티 선택, 직접 기입 등) 할 수 있도록 개선하는 요구사항을 받았다. 현재는 RDMBS에 데이터를 저장하고 있고, 기존의 엄격한 스키마 요구사항은 확장된 기능으로 변경하기에 시간과 비용이 많이 들며, 유연한 설문조가 기능은 DB 구조를 매우 복잡하게 만든다. 
선택할 수 있는 옵션으로는 PostgreSQL의 JSONB 데이터 타입 또는 몽고DB(MongoDB)와 같은 문서 저장소가 있다.

 

 

결정

몽고DB로 결정함

유연한 설문조사 기능을 만들려면 문서 데이터베이스로 옮기면 유연성과 속도가 증가되고, 고객 설문조사의 UI 개발을 단순화시켜 변화를 더 잘 수용할 수 있을 것이다. 

 

 

• 결정은 사실에 근거한 중립적인 결정으로 작성하는 것
• ~라 생각한다. ~라 믿는다. 와 같은 주관적인 표현은 적절하지 않다. 결정 당시 기술 수준과 요구되는 아키텍처의 특성(단순, 복잡, 확장성, 응답성능, 기타 등등), 주어진 리소스(타당성) 등의 근거 안에서 왜 이런 결정을 했는지 객관적으로 작성해야 한다.
• 결정에 들어갈 내용은 재판의 판결문을 작성하는 것과 유사하다.

 

결과 

몽고DB로 변경하기 위해 기존 RDBMS에 저장된 데이터를 문서 형식으로 마이그레이션해야 한다. 
기존 단순 설문조사에 맞춰 구성된 DB Schema와 Frontend 설문 콤포넌트를 다양한 설문 형식에 맞게 기능을 제공하도록 설문 형식과 콤포넌트 구성을 고려해서 문서 구조를 설계해야 한다.

저장소 이관 시 몽고DB로 데이터를 마이그레이션하는 동안 시스템 다운타임(서비스 점검)이 발생할 것이다.

(참고 : RDBMS와 몽고DB를 이중 지원하도록 하위 호환성 지원 기능을 개발해서 다운타임을 없앨 수 있으나, 새벽 시간 1시간 정도의 다운타임을 위해 하위 호환성 지원 기능은 오버엔지니어링으로 판단되어 마이그레이션 시간 동안 서비스 점검을 하는 것이 합리적이다.)

 

 

 

 

ADR 작성은 어디에?

• 형상관리 시스템(Git, Bitbucket)이나 WIKI
• 누구나 작성하고, 검색하기 쉽게
• ADR의 범위는 조직 규모, 도메인 등 

 

 

아마존 창시자 제프 베조스

아미존 내의 모든 서비스는 API를 통해서만 다른 서비스와 소통할 수 있다

 

세계에서 아마도 가장 유명한 아키텍처 결정은 아마존의 창립자 제프 베조스가 아마존에 선언한 ADR