“헤드 퍼스트 소프트웨어 아키텍쳐” 에서 나온 ADR(Architectural Decision Record)에 대해서 정리해보려고 합니다.

ADR(Architectural Decision Record)

구성은 아래와 같습니다.

## 제목 
## 상태
## 맥락
## 결정
## 결과
## 거버넌스
## 노트

아래는 제가 개발하고 있는 프로젝트에 적용해 가면서 작성한 ADR의 예시입니다. (실제 프로젝트에서 작성한 ADR을 기반으로 작성하였으며, 일부 내용은 이해를 돕기 위해 수정되었습니다.)

제목 -> 번호는 001부터 시작해서 999까지 있고, 제목은 매우 신중하게 작성하라고 한다.

001 : 채팅 서비스를 위해서 관계형 데이터베이스(postgreSQL)을 사용함: 승인, 024로 대체됨.

상태 -> 의견 요청(항상 ‘응답 기한’이 있어야 한다), 제안, 승인

당연히, 개발과정에서 대체되는 부분이 생길 수 밖에 없고, 아래와 같은 형식으로 작성하라고 합니다.

024 : 채팅 서비스의 데이터베이스로 Cassandra를 사용하기로 결정함: 승인, 001을 대체함.

기존 문서에도 업데이트를 하고 새로운 문서에도 업데이트를 하는 방식을 가져가는 형태로, ADR이 계속해서 진화하는 문서라는 것을 보여주는 형태입니다.

맥락 -> 문제의 배경과 맥락을 설명하는 부분

채팅 서비스에선 실시간 메시지 전송과 높은 쓰기 처리량이 중요하다. PostgreSQL은 관계형 데이터베이스로서 트랜잭션과 복잡한 쿼리를 지원하지만, 대규모 채팅 서비스에서는 쓰기 처리량이 병목이 될 수 있다. 또한, 채팅 메시지는 일반적으로 단순한 키-값 형태로 저장되며, Cassandra와 같은 분산형 NoSQL 데이터베이스가 이러한 요구사항에 더 적합할 수 있다.

결정 -> 내린 결정과 그 이유를 설명하는 부분

채팅 서비스는 실시간 메시지 전송과 높은 쓰기 처리량을 요구하므로, Cassandra와 같은 분산형 NoSQL 데이터베이스를 사용하기로 결정하였다.

결과 -> 결정의 결과와 영향을 설명하는 부분

Cassandra를 사용함으로써 채팅 서비스는 높은 쓰기 처리량과 실시간 메시지 전송을 가능하게 되었으며, 시스템의 성능과 확장성이 향상되었다.

거버넌스 -> 결정의 관리와 감독을 설명하는 부분

즉, 위에서 팀원들과 많은 시간을 들여서 ADR을 작성한 뒤에, 결정이 올바르게 이행되고 있는지, 계속 그렇게 잘 하고 있는지 확인하는 부분이 필요하다고 합니다. -> “진화적 아키텍쳐”라는 책에서 거버넌스를 위한 내용이 나오니 추후에 공부해보고 업데이트하겠습니다.

ADR은 모든 아키텍처 결정에 대해 문서화되며, 팀원 간의 소통과 협업을 촉진한다.

노트 -> ADR자체에 대한 메타데이터

• 원저자
• 승인 날짜
• 승인한 사람
• 마지막 수정 날짜
• 수정한 사람
• 마지막 수정

다른 내용들은 Event-Driven, DDD, Mircroservices, 소프트웨어 공학 책에 있는 내용들과 겹치기에 따로 작성하지는 않겠습니다.

마치며

이 책을 중간고사 끝나고 읽어서, ADR 문서 작업을 하지는 못한게 아쉽지만, 다음에 팀 프로젝트가 있다면 그 때는 한번 적용하려고 합니다.

책에서 나온 내용들의 일부분이 26년도 팀 프로젝트에서 Event-Storming을 하면서 토의했던 내용들과 겹치는 부분이 많았고, 나름대로 잘한 부분이 많았다는 생각이 들었습니다.

다음은 위에 진화적 아키텍쳐나 다른 재밌는 책이 있으면 업데이트 하도록 하겠습니다.