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

9.3 새로운 요구 사항 구현하기
- 정말 코드를 변경하기 쉽게 했는지 체크
- 사물을 두 단위의 UoW에 걸쳐 나누면 DB 트랜잭션이 2개 생기기에 데이터 정합성 문제가 발생할 수 있음.

9.4 새 핸들러 시범 운영하기
- '높은 기어비'를 사용해 일하면서 단위 테스트를 가장 최상위 수준에서 작성할 수 있음.

9.5 선택: 가짜 메시지 버스와 독립 적으로 이벤트 핸들러 단위 테스트하기
- '가짜' 메시지 버스를 사용해서 이벤트 연쇄의 복잡도에 따라 다른 핸들러와 독립적으로 일부 핸들러를 테스트.

시스템을 어떻게 변경했는가?
- 이벤트는 시스템 안의 내부 메시지와 입력에 대한 데이터 구조를 정의하는 간단한 데이터 클래스
- 이벤트는 비즈니스 언어로 매우 자 번역되기에 DDD 관점에서 강력한 개념.
- 핸들러는 이벤트에 반영하는 방법. 모델을 호출하거나 외부 서비스를 호출할 수 있음. 하나의 이벤트에 여러 핸들러를 정의할 수 있으며 다른 이벤트를 만들 수도 있음.
- 핸들러가 수행하는 일의 크기를 세밀하게 조절해서 SRP를 유지할 수 있음.

왜 이렇게 시스템을 변경했는가?
- 아키텍처 패턴을 채택한 목적은 애플리케이션의 크기가 커지는 속도보다 복잡도가 증가하는 속도를 느리게 만들기 위함.
- 메시지 버스에 모든 것을 실으면 아키텍처의 복잡도 측면에서는 비용을 지불하지만, 필요한 작업을 수행하기 위해 더 이상 개념적으로나 아키텍처적으로 코드를 변경할 필요 없이 대부분의 복잡한 요구사항을 처리할 수 있는 패턴을 얻을 수 있음.