[책] 파이썬으로 살펴보는 아키텍처 패턴

CH0. 도입

0.1. 설계가 왜 잘못되는가?

시스템을 처음 구축할 때

• 원대한 계획을 세움 (코드를 깔끔하게 질서 잡힌 상태로 유지하기 위해)
  하지만 시간이 지남에 따라 잘못 구현 or 엣지 케이스에 의해 망하게 됨

0.2. 캡슐화와 추상화

캡슐화

• 행동의 단순화 & 데이터 감추기
• 코드에 수행할 작업 식별 -> 객체나 함수를 부여

추상화

• 객체나 함수를 추상화라 함

import requests

parsed = requests.get(<some_url>).json()

잘 추상화 된 예시

한단계 더 나아가면 작업을 식별하고 이름을 부여해서 더 높은 수준의 추상화를 할 수 있음

import duckduckgo

ductductgo.query('Sausages').results

책임 주도 설계 : 코드를 데이터나 알고리즘이 아니라 행동을 중심으로 생각

0.3. 계층화

캡슐화와 추상화를 하면 세부사항을 감추고 데이터의 일관성을 보호할 수 있음

3계층 아키텍처

[Three-Tier Client-Server Architecture in Distributed System - GeeksforGeeks](https://www.geeksforgeeks.org/three-tier-client-server-architecture-in-distributed-system/)

이 책의 나머지 부분은 3계층 모델을 한가지 원칙에 집중하는 모델로 변경할 것 (흠)

0.4. 의존성 역전 원칙

SOLID의 D인 의존성 역전 원칙 (Dependency inversion principle - DIP)

정의

1. 고수준의 모듈을 저수준의 모듈에 의존해서는 안 된다. 두 모듈 모두 추상화에 의존해야 한다.
2. 추상화는 세부 사항에 의존해서는 안 된다. 반대로 세부사항을 추상화에 의존해야 한다.

서로 독립적으로 변경하길 원함 (고수준 & 저수준)

• 고수준 : 비즈니스의 필요에 따라 쉽게 변경 가능해야 함

이 둘 사이에 추상화를 사용하면 두 계층이 서로 독립적으로 변경될 수 있다.

CH1. 도메인 모델링

CH2. 저장소 패턴

CH3. 막간: 결합과 추상화

CH4. 첫 번째 유스 케이스: 플라스크 API와 서비스 계층

CH5. 높은 기어비와 낮은 기어비의 TDD

CH6. 작업 단위 패턴

CH7. 애그리게이트와 일관성 경계

CH8. 이벤트와 메시지 버스

CH9. 메시지 버스를 타고 시내로 나가기

CH10. 커맨드와 커맨드 핸들러

CH11. 이벤트 기반 아키텍처: 이벤트를 사용한 마이크로서비스 통합

CH12. 명령-질의 책임 분리(CQRS)

CH13. 의존성 주입(그리고 부트스트래핑)

CH14. 맺음말