[나는 리뷰어다] Fundamentals of Software Architecture

이 책은 소프트웨어 아키텍처 설계에 대한 다양한 방법에 대해서 써놓은 책이다. 설계 뿐만 아니라 아키텍트가 알아야 하는 것들 또는 고려해야 하는 상황들도 다양한 관점에서 설명을 해준다. 책을 읽으면서 몇가지 내가 기억해두면 좋을것 같다는 부분들을 아래와 같이 작성해봤다.

아키텍처 대 설계

- 아키텍트와 개발자를 나누는 가상의 물리장벽을 통과하는 단방향 화살표는 많은 문제를 야기한다. 따라서 아키텍처, 설계 모두 소프트웨어 프로젝트 생명 주기의 일부로서 항상 서로 동기화되어야 성공할 수 있다.

아키텍처와 코딩 실무간 균형 맞추는 방법
1. POC를 자주 해본다. 가능한 한 프로덕션 수준의 고품질 코드로 작성하는 것이 좋다.
2. 기술 부채나 아키텍처 스토리에 전념한다. 또는 버그를 수정한다.
3. 코드리뷰를 자주한다.

아키텍처 특성 식별
1. 도메인 관심사에서 아키텍처 특성도출
  - 도메인의 핵심 목표와 현재상황 고려하여 아키텍처 결정
  - 모든 아키텍처 특성을 지원하는 제네릭 아키텍처 설게 --> 가장 흔한 안티패턴
  - 가급적 설계를 단순화 하는게 좋다
2. 요구사항에서 아키텍처 특성 도출

컴포넌트 식별흐름

1. 초기 컴포넌트 식별
2. 요구사항을 컴포넌트에 할당
3. 역할 및 책임 분석
4. 아키텍처 특성 분석
5. 컴포넌트 재구성
위 그림처럼 컴포넌트 식별은 한번에 끝나는게 아니라 컨포넌트의 특성을 분석해 나가면서 계속해서 수정될 수 있다.

컴포넌트 설계
- 엔티티 함정
   각각의 엔티티를 바탕으로 컴포넌트를 만드는것. 이건 프레임워크를 데이터베이스에 컴포넌트 관계형으로 매핑한 것에 불과한것이다. (내가 항상 이렇게 설계를 하고 있지 않나 싶다... )
- 액터/액션 접근법
   애플리케이션에서 뭔가 일을 하는 액터와 그들을 수행하는 액션으로 식별
- 이벤트 스토밍
   다양한 컴포넌트가 메시지나 이벤트를 이용해 서로 통신한다고 가정.
   어떤 이벤트가 일어나는지 파악하고 컴포넌트를 이벤트와 핸들러 중심으로 구축.
- 워크플로 접근법
   이벤트 스토밍의 대안으로 DDD나 메시징을 사용하지 않고 더 일반화 한 방법.
   핵심 역할을 식별하고 이 역할이 관여하는 워크플로 유형을 결정하여 식별된 활동에 따라 컴포넌트 구축.

아키텍처 스타일 : 크게 모놀리식과 분산형으로 나누면 다음과 같은 아키텍처들이 존재한다.
- 모놀리식
   레이어드 아키텍처, 파이프라인 아키텍처, 마이크로커널 아키텍처
- 분산형
   서비스 기반 아키텍처, 이벤트 기반 아키텍처, 공간기반 아키텍처, 서비스 지향 아키텍처, 마이크로서비스 아키텍처 

아키텍처 결정의 안티패턴
- 네 패를 먼저 보여주지마
  아키텍트가 잘못된 선택을 하는 것을 두려워해서 아키텍처 결정을 회피하거나 미루는 현상
  개발팀과 지속적으로 협력하면서 결정한 내용을 의도한 대로 추진 가능함. --> 모든 이슈를 아키텍트가 혼자 다 알수 없기 때문에 개발팀과 협력은 절대적임.
- 무한반복 회의
  어떤 결정을 왜 했는지 모르고 주구장창 회의만 계속 하는것.
  무한반복 회의가 발생하는 이유는 아키텍트가 자신이 내린 결정을 정당화 하는데 실패했기 때문
  아키텍처 결정을 할때 비즈니스 가치를 제시하는 것이 중요함.
- 이메일 기반 아키텍처
  아키텍처 결정을 놓치거나 잊어버리고 심지어는 그렇게 결정됐다는 사실조차 알지 못해 아키텍처 결정을 구현하지 못하는 상태.
  즉, 아키텍처 결정을 효과적으로 전달하지 못해서 발생하는 문제.
  이메일 본문에 아키텍처 결정을 포함하지 않는다. 중요한 세부사항은 단일 기록시스템(위키페이지등)에 보관해서 링크만 제공한다.
  아키텍처 결정에 정말 관심이 있는 사람들에게만 통지한다.
 

협상과 조정 tips
- 상황을 더 잘 이해하기 위해 문법과 유행어를 사용한다.
- 협상에 돌입하기 전 가능한 한 많은 정보를 수집한다.
- 다른 모든것이 실패하면 비용과 시간으로 설명한다.
- '분할 및 정복' 규칙을 활용해서 요구사항 또는 필우 조건을 검증한다.
- 증명은 언제나 논쟁을 이긴다는 사실을 명심한다.
- 지나치게 논쟁을 벌이려고 하거나 협상 과정에서 개인정인 감정을 드러내지 않는다. 간결 명료한 추론에 차분한 리더십을 더하면 반드시 협상에 승리한다.
- 개발자가 아키텍처 결정을 수용해서 어떤 작업을 하도록 설득할 때에는 '고압적으로 지시' 하지 말고 왜 그 일을 해야 하는지 정당성을 제공한다.
- 개발자가 아키텍트의 결정에 동의하지 않을 경우 그들 스스로 해결책을 찾도록 유도한다.

위 내용들 중에서도 특히 엔티티 함정 과 아키텍처 결정 안티패턴은 읽으면서 나 자신이 반성을 많이 하게 되었다. 아마도 내가 그런 안티패턴에 빠져서 설계를 하지 않았나라는 느낌이 많이 들었기 때문이다. 아키텍처에 대한 기초 지식을 얻고자 하는 분들에게 큰 도움이 될수 있는 책이라고 생각한다. 

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."