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

0.1 설계가 왜 잘못되는가?
- 카오스(Chaos) : 균일성(같음)
- 질서(Order) : 복잡성(다름)
- 소프트웨어 시스템은 혼돈 상태로 향하려는 경향이 있음.
- 처음 구축할 때는 코드를 깔끔하게 질서 잡힌 형태로 유지하기 위한 계획을 세우지만, 시간이 지남에 따라 에지 케이스(잘 일어나지 않는 드문 경우)를 처리하기 위한 코드가 점점 늘어나면서 결국 혼란스러운 늪에 빠지게 된다.
- 합리적으로 잘 계층화된 아키텍처도 결국엔 온갖 코드가 엮인 잡탕으로 끝나는 경우가 있다.
- 무질서 소프트웨어 시스템은 기능의 동일성을 특징으로 한다.
- 모든 요소가 다른 요소와 결합(coupling)되어 있어서 시스템의 일부를 바꾸는 것은 위험하다.
- 이런 혼동 상태를 '큰 진흙 공(big ball of mud) 안티 패턴'이라고 한다.

0.2 캡슐화와 추상화
- 정확한 용어로 표현하지 못할 수 있지만 본능적으로 사용하는 도구라고 볼 수 있다.
- 캡슐화 : 행동의 단순화와 데이터 은닉이라는 두 가지 단어가 밀접하게 연관된 아이디어를 뜻함. 코드에서 수행할 작업을 식별하고 이 작업에 잘 정의된 객체나 함수를 부여하여 행동을 캡슐화.
- 추상화 : 행동을 캡슐화해주는 객체나 함수를 의미.
액션을 추상화로 캡슐화하는 것은 코드의 표현력을 더 높이고 테스트와 유지보수를 더 쉽게 만드는 강력한 도구다.

0.3 계층화
- 캡슐화와 추상화를 통해 세부사항을 감추고 데이터의 일관성 보호 가능. 그러나 객체와 함수들의 상호작용에도 주의를 기울여야 함.
- 어떤 함수나 모듈, 객체인 A가 다른 함수나 모듈, 객체인 B를 사용할 때 'A가 B를 의존한다'라고 한다.
- 큰 진흙 공에서는 의존성이 제어 불가능할 정도로 복잡하다. 시스템에 여러 부분에 영향을 줄 수 있기에 특정 한 노드만 변경하기가 어렵다. 
- 이를 해결하기 위해 계층화된 아키텍처를 사용한다. 코드를 서로 구분하는 범주나 역할로 분할하고, 어떤 코드 범주가 어떤 코드 범주를 호출할 수 있는지에 대한 규칙을 도입한다.
- 가장 일반적인 예로 3 계층 아키텍처(표현 계층, 비즈니스 로직 계층, 데이터베이스 계층)가 있다.

0.4 의존성 역전 원칙(Dependency Inversion Principle)
- 고수준 모듈은 저수준 모듈에 의존해서는 안 된다. 두 모듈 모두 추상화에 의존해야 한다.
- 추상화는 세부 사항에 의존해서는 안된다. 반대로 세부 사항은 추상화에 의존해야 한다.
- 고수준 모듈 : 조직에서 정말 중요하게 여기는 코드.
- 저수준 모듈 : 조직에서 신경 쓰지 않는 코드.
- 의존성 : 꼭 임포트나 호출만을 의미하지 않음. 다른 모듈을 필요로 하거나, 알고 있다는 좀 더 일반적인 생각이 의존성이다.

0.5 모든 비즈니스 로직을 위한 장소 : 도메인 모델
- 보통 설계가 가장 잘못되는 일반적인 경우는 비즈니스 로직이 애플리케이션 전 계층에 퍼지는 경우다. 이렇게 되면 비즈니스 로직을 식별하고, 이해하고, 변경하기가 어려워진다.