1. 도메인 모델링을 지원하는 아키텍쳐 구축
- 저장소 패턴은 영속적인 저장소에 대한 추상화다.
- 서비스 계층 패턴은 유스 케이스의 시작과 끝을 명확하게 정의하기 위한 패턴이다.
- 작업 단위 패턴은 원자적 연산을 제공한다.
- 애그리게이트 패턴은 데이터 정합성을 강화하기 위한 패턴이다.
1-1. 도메인 모델링
- 이 패턴이 전회사 flask 구조와 비슷하다는 생각이 들었다. (controller, service, dao)
- 비지니스 로직 계층 = 3계층으로 이루어진 아키텍쳐의 핵심 계층 = 도메인 모델
- 도메인이란? 해결하려는 문제
DDD 책을 꼭 읽어봐야 한다. (도메인 주도 설계(위키북스), 도메인 주도 설계 핵심(에이콘출판사))
> 도메인 모델을 이해하려면 시간과 인내, 수많은 포스트잇 메모가 필요하다...비즈니스 전문가들과의 대화...
- 첫 직상에서 한 일이 결국 DDD인가...?
타입힌트
- 내기준에선 가독성이 너무 떨어져서 불편. 선호하지 않는 편.
__eq__, __hash__
__eq__를 변경하지 않았다면__hash__를 변경해선 안된다.
inheritance, composition
- 면접 때 받은 질문
- django는 composition > inheritance라고 한다.
1-2. 저장소 패턴
저장소 패턴은 영속적 저장소를 추상화한 것이다.
핵심 로직과 인프라 관련 사항을 분리하는 방법으로 의존성 역전 원칙을 사용
추상화가 데이터베이스의 복잡성을 감춰서 시스템을 테스트하기 더 좋게 만든다.
이 책에서 사용하는 프레임워크가 덜 중요해지는 방법을 보여준다.
각 계층이 자신의 바로 아래 계층에만 의존하게 만드는 것이 목표다.
ORM이 제공하는 가장 중요한 기능은 역속성 무지(persistence ignorance)다. 도메인 모델이 데이터를 어떻게 적재하는지 또는 어떻게 영속화하는지에 대해 알 필요가 없다는 의미다.
영속성 무지가 성립하면 특정 데이터베이스 기술에 도메인이 직접 의존하지 않도록 유지할 수 있다.
...
이런 관점에서 보면 ORM을 사용하는 것은 이미 DIP의 한 예다. 하드코딩한 SQL에 의존하는 대신 추상화인 ORM에 의존한다. 하지만 이것만으로는 충분하지 않다.
이해 안되는 부분
1.
2.
1-3. 막간: 결합과 추상화
목차
- 추상적인 상태는 테스트를 더 쉽게 해준다.
- 올바른 추상화 선택
- 선택한 추상화 구현
3-1. 의존성 주입과 가짜를 사용해 에지투에지 테스트
3-2. 패치를 사용하지 않는 이유
1. 추상화: 결합도를 낮춰줌
- 결합(coupling): 상호 의존하는 정도 또는 연관된 관계.
B 컴포넌트가 깨지는 게 두려워서 A 컴포넌트를 변경할 수 없는 경우 결합이 높다. - best: 자료 결합도 (여기 참고)
- worst: 내용 결합도(여기 참고)
- 응집(cohesion): 한 모듈 내부의 처리 요소들이 서로 관련되어 있는 정도. 높을 수록 좋다.
- best: 기능적 응집도(모듈 내의 모든 요소들이 하나의 기능을 수행하기 위해 구성된 경우. 예, requests library)
- worst: 우연적 응집도
- 결합도를 낮춰야 좋은 아키텍쳐이고, 이를 위해 추상화를 사용한다.
2. 추상화: 테스트를 더 쉽게 해줌.
1-4. 첫 번째 유스 케이스: 플라스크 API와 서비스 계층
의존성 주입
의존성이란?
Dependency between two components is a measure of the probability that changes to one component could affect also the other
코드가 복잡해지만 필연적으로 다양한 객체 간의 협력 관계가 만들어진다. 협력하기 위해서는 다른 객체가 존재한 다는 사실을 알고 있어야 하고, 다른 객체가 어떤 방식으로 "메시지"를 수신하는 지도 알고 있어야 한다. 이러한 객체의 지식이 의존성을 만든다 (오브젝트를 참고했음)
애플리케이션 설계가 유연해지려면, 실행 컨텍스트에 대한 구체적인 사항을 최소한으로 지니고 있어야 한다. 그래야 기능 추가, 로직 변경 또는 테스트를 작성하는 데도 수월한 코드를 만들 수 있다.
의존성 주입이란?
사용하는 객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법을 의존성 주입이라고 부른다.
왜 의존성 주입이 필요한가?
객체의 생성을 다른 곳(컨테이너)에서 담당해서 결합도를 낮춘다
낮은 결합도로 변경에 용이하고, 다른 객체와의 협력 관계에 더 집중하게 해준다
Fake, Mocking 객체를 주입해 테스트하기 쉽게 만든다
출처: https://www.humphreyahn.dev/blog/dependency-injector
1-5. 높은 기어비와 낮은 기어비의 TDD
1-6. 작업 단위 패턴
1-7. 에그리게이트와 일관성 경계
