0장에서 1장까지의 내용 정리

1. Architecture Patterns
with Python
(1)
김동환(wraithtorch@gmail.com)

2. 참고 자료
영어로는 무료로 제공함.
사고 나서 깨달음.
번역본만 보는 건 어감이 좀 안 맞아서
추천 안함.
http://www.cosmicpython.com/book/pref
ace.html

3. 원래 의도와 현실
난 이거 DDD(도메인 주도 설계)에 대해서 알고 싶어서 샀었음. ebook이라 편한
것도 있었고.
하지만 이 책은 DDD를 자세히 설명하는 책이 아님. 읽어보니까
Python에서는 이런 아키텍쳐 패턴을 어떻게 구현할까에 초점이 맞춰진 책임.
따라서 만약 Python을 쓰지 않는다면 이 책의 효과는 절감됨.언어적 특성 때문에
다른 언어에선 쓸 수 없는 방법도 소개하기 때문.

4. 오늘 뭔 얘기 할 거에요?
0. 도입부
1. 도메인 모델이 무엇인가?
이것만 얘기 할거임.

5. 설계가 왜 잘못 되어 가는가?
소프트웨어에 기능이 추가 되다 보면
자연스럽게 혼돈 상태로 가게 됨.
그래서 우리는 에너지를 소비해서 질서
상태로 돌려야 함.
너무 복잡해서 진흙공처럼 되어버린 의존성 그래프

6. 그럼 어떻게 해야 하는가
우리가 알고 있는 것
1. 캡슐화와 추상화
캡슐화는 데이터 은닉과 행동의 단순화를 하기 위해서 씀.
우리가 코드로 구현하려고 하는 기능을 캡슐화한 함수나 객체를 추상화라 부름.
캡슐화와 추상화를 쓰는 건 코드의 표현력을 높이고 테스트와 유지보수를 쉽게
하기 위함.

7. 그럼 어떻게 해야 하는가
2. 계층화
코드를 카테고리로 분류한 다음, 인접한 카테고리만 호출할 수 있게 함.
복잡한 의존성을 해결하는 대표적인 방법

8. 그럼 어떻게 해야 하는가
3. 의존성 역전 원칙
두 개의 의미를 가짐.
1. 고수준 모듈은 저수준 모듈을 의존해선 안 됨. 둘 다 추상화에 의존해야 함.
2. 추상화는 세부 사항에 의존해서 안됨. 대신 세부 사항은 추상화에 의존해야 함.
고수준은 우리가 중요하게 여기는 코드를 말함. ex) 은행 - 외환 기능
저수준은 중요하지 않은 코드를 말함. ex) HR 조직 - 네트워크 소켓, 프로토콜

9. 그럼 어떻게 해야 하는가
이 책에선 위에서 말한 꼬여가는 설계를 풀기 위한 몇 가지 방법들을 소개함.
이러한 패턴들은 추상화, 계층화 의존성 역전에 기반해서 이해할 수 있음.
따라서 이 책을 읽으면서 얻어갔으면 하는 건
1. 어떤 방법을 쓸 수 있는지
2. 각각의 방법에 트레이드오프(장단점)이 뭔지
를 알아서 나중에 있을 프로젝트에 도움이 되길 바람.

10. 1장. 도메인 모델
비즈니스 로직은 어플리케이션 전체 계층에 퍼지면 안됨.
이해하거나 수정하는게 힘들어짐.
도메인 모델은 이런 비즈니스 로직을 집중시키기 위한 방법임.

11. 도메인에 대해 알기
도메인 모델링의 핵심은 도메인, 즉 해결해야 할 문제에 초점을 맞춰야 됨.
도메인을 이해한 후에 중요한 부분을 뽑아서 지도(모델)를 만듦.
언어나 DB를 선택하는 등의 과정들이 절대 문제를 이해하는 것보다 선행되선 안됨.

12. 도메인에 대해 알기
예로 들어 가구 구매 시스템을 만든다면,
이 과정을 전부 이해하고 있어야 됨.
모르면 도메인 전문가에게 물어봐서라도
알아야 됨.

13. 유비쿼터스 언어
도메인에서 쓰는 전문용어를
‘유비쿼터스 언어’라고 함. 이건 해당
도메인이 발전하면서 계속해서 쓴
관용구이기 때문에 따라야 함.
왼쪽의 가구 구매 서비스 명세서에도
‘SKU’, ‘배치’, ‘라인’ 이라는 유비쿼터스
언어가 있고, 이 단어들은 코드에 그대로
반영되어야 됨.

14. 단위 테스트 만들기
이전에 본 그 명세서를 기반으로 테스트를 먼저 만듦.
이 예시에선 할당에 대한 테스트를 함.
‘창고에 적재될 재고’를 batch라고 하고, ‘고객이 구매한 주문 목록 중 한 항목’을 line이라고 함.
batch에 line을 할당하면 고객이 주문한 수량만큼 재고에서 줄어드는 걸 테스트하는 것임.

15. 테스트를 통과하기 위한 객체와 함수 만들기
만든 테스트를 통과하기 위해 다음과 같은 코드를 작성함. 물론 이 코드들도
유비쿼터스 언어를 사용해서 적어야 함.

16. 도메인 개념 표현하는 방법: 값 객체와 엔티티
Batch나 Line 같은 개념을 객체화 할 때 두 개의 경우로 나눠짐.
객체에 포함된 값이 더 중요하면 ‘값 객체’(Value Object)
객체의 정체성을 구분해야 한다면 ‘엔티티’(Entity) 로 나눔.

17. 값 객체(Value Object)
값 객체는 유일한 식별자 같은 게 없어서 구분할 수 없는 개념을 말함.
예로 들어 지폐는 거래 시스템을 모델링한다 치면, 지폐가 가진 값어치가 중요하지
같은 5달러 짜리 지폐를 서로 다른 지폐로 구분하지 않음.
따라서 값이 바뀌면 이전과 다른 객체로 인식함. 그래서 보통 값 객체는
immutable하게 구현함. 그리고 내부 속성들의 모든 값이 같으면 객체가 같다고
보는데 이걸 ‘값 동등성’이라 부름.

18. 엔티티(Entity)
반대로 엔티티는 내부의 값들이 아닌 객체 자체에 정체성이 있음.
예로 들어 사람은 이름이 바뀌든 성별이 바뀌든 같은 사람이라고 인식하기 때문에
‘영속적인 정체성’이 있다고 할 수 있음.
그래서 값이 바뀌더라도 같은 엔티티임을 인식하는 걸 ‘정체성 동등성’이라고 함.
이를 위해서 equal 함수나 hash 함수를 오버라이드 해야할 수도 있음.

19. 도메인 서비스 함수
분명 해당 도메인에서 일어나는 비즈니스 개념이거나 프로세스인데, VO나 Entity로
표현하기 어려운 게 있음. 이런걸 도메인 서비스 함수라고 함.
Python은 클래스 없이도 함수를 작성할 수 있으니 이런건 그냥 함수로 표현하는게
맞음.

20. 예외 객체
우리가 아는 Exception 클래스를 상속받은 객체를 말함. 여기서도 주의할 건
유비쿼터스 언어로 표현해야 한다는 것. 예외도 충분히 도메인 개념을 표현할 수
있음.
예로 들어, 가구 주문 시스템에선 품절 예외를 처리할 때 명세서에 적힌 대로
클래스명을 OutOfStock이라고 해야 함.

21. 다음 장에선 뭔 얘기 할거임?
이렇게 VO나 Entity 등을 써서 할당이라는 use case에 대해서 도메인을 구현함.
하지만 메모리에 올리기 힘든 데이터를 다루기 위해 DB 같이 외부에 데이터를
저장하고 가져오는 것도 추가할 수 있음.
하지만 도메인 계층은 다른 곳에 의존하지 않는게 좋음. 그래서 DB를 추상화해서
도메인을 건드리지 않고도 DB를 교체하거나 Mock객체로 대체하기 쉽게 해주는
저장소 패턴을 설명할거임.