파이썬으로 살펴보는 아키텍처 패턴 - 14장 #3

14.7 기술 리뷰어들의 질문
- 이 모든 것을 한 번에 적용해야 하는가? 조금씩 적용은 불가한가? : 당연히 조금씩 적용해도 됨. 기존 시스템이 있다면 서비스 계층을 만들어서 오케스트레이션을 한 곳에 모으는걸 권함.
- 일단 서비스 계층이 생기면 로직을 모델에 넣고 검증이나 오류 처리 같은 미묘한 관심사를 진입점에 넣기가 쉬움.
- 유즈 케이스를 추출하면 기존 코드 중 상당 부분이 망가진다면? : 그냥 복사해서 붙여 넣는걸 권함. 단기적으로는 더 많은 중복도 가능. 큰 코드 기반을 고치는 과정은 지저분하고 고통스러운 프로세스.
- 모든 게 순식간에 좋아지리라 기대하지 말고, 애플리케이션의 일부가 더 지저분해지더라도 걱정하지 말 것.
- CQRS가 꼭 필요한지? : 저장소만 써도 됨. 이 책의 기법들은 삶에 더 쉽게 도움이 되려고 하는 것. 반드시 강제로 지켜야 하는 규율은 아님.
- 큰 시스템에서 유스 케이스가 어떻게 서로 상호 작용하는지? 어떤 유스 케이스가 다른 유스 케이스를 호출하면 문제가 생기는지? : 메시지 버스를 이용해 관심사 분리가 필요할 수 있다. 
- 여러 저장소나 애그리게이트를 사용하는 유스 케이스인가? : 애그리게이트는 일관성 경계이므로 유스 케이스가 두 애그리게이트를 원자적으로 업데이트해야 한다면 일관성 경계가 잘못된 것. 이상적으로는 동시에 변화시키려는 모든 대상을 포함한 새로운 애그리게이트로 옮겨야 하는지 생각해봐야 함.
- 읽기 전용이지만 비즈니스 로직이 많이 있는 시스템이라면? : 뷰 모델에 복잡한 로직이 있을 수도 있음. 읽기와 쓰기 모델의 일관성과 스루풋 요구사항이 달라 두 모델을 분리하는 걸 권함. 대부분의 경우 읽을 때는 간단한 로직을 쓰지만 항상 그렇지는 않음. 특히 권한과 인증 모델이 있으면 읽는 부분에서 복잡도 증가.
- 마이크로 서비스로 꼭 만들어야 하는가? : 그럴 필요는 없음. 꼭 필요하지 않음.
- 장고는 계속 써도 되는가? : 부록에 해당 내용 남겨둠.

14.8 풋건
- 신뢰성 있는 메시징은 어렵다 : 레디스 발행자/구독자는 신뢰할 수 없고, 일반적인 메시징 도구로 사용하면 안 됨. 
- 서로 독립적으로 실패할 수 있게 작고, 초점이 한정된 트랜잭션을 명시적으로 선택
- 멱등성에 대해서는 다루지 않음 : 핸들러를 재시도할 시 어떤 일이 발생하는지에 대해서는 다루지 않음. 실전에서는 핸들러를 멱등적으로 만들어 같은 메시지로 핸들러를 반복 호출해도 상태 변경이 단 한 번만 일어나게 해야 함.
- 시간이 지나면 이벤트의 스키마를 바꿔야 할 수도 있음 : 이벤트를 문서화하고, 스키마를 고객과 공유할 방법을 찾을 필요가 있음. 그래서 JSON 스키마와 마크 다운을 선호.