docs: 3.1 이준서 정리글 업로드

도메인 주도 설계 첫걸음/Part03. 도메인 주도 설계 적용 실무/Section10. 휴리스틱 설계/glay415.md

@@ -0,0 +1,123 @@
+# Part 3 도메인 주도 설계 적용 실무
+
+3부에서는 이론이 아닌 실무를 다루고 실제 프로젝트에 도메인 주도 설계를 적용하는 것을 배운다.
+
+### 01 _ 비즈니스 도메인 분석하기
+
+---
+
+이번장에선 다양한 소프트웨어 설계 의사결정, 즉 (비즈니스) 도메인 주도 (소프트웨어) 설계를 돕는 분석 도구를 사용하는 휴리스틱을 배운다.
+
+#### 휴리스틱
+
+---
+
+휴리스틱은 완벽한 것을 보장하지 않지만 당면한 상황에 충분할 만큼의 경험에 기반한 규칙이다.
+
+휴리스틱을 사용하는 것은 수많은 단서에 내재된 노이즈를 무시하면서도 가장 중요한 단서에서 느껴지는 '압도하는 힘'에 집중하여 효과적으로 문제를 해결하는 접근법 이다.
+
+
+
+#### 바운디드 컨텍스트
+
+---
+
+>  **"한 서비스의 경계를 정의하는 데 있어 식별을 용이하게 해주는 유용한 휴리스틱은 매우 많다. 그러나 그중 크기(size)로 경계를 구분하는 것은 가장 도움이 되지 않는다." **
+>
+> **- 닉 튠(Nick Tune)**
+
+작은 바운디드 컨텍스트로 만들려고 기능을 원하는 크기에 최적화하는 것보다는 그 반대로 하는 것이 훨씬 더 효과적이다.
+
+비싸고 수많은 조율이 필요한 상황은 바운디드 컨텍스트 경계의 설계가 효과적이지 않다는 신호다.
+
+바운디드 컨텍스틍의 경계를 리팩터링하는 것은 비용이 많이 드는 작업이고 대부분의 경우 효과적이지 않은 경계는 방치되고 결국 부채로 남게 된다.
+
+
+
+넓은 바운디드 컨텍스트의 경계 또는 여러 하위 도메인에 걸친 경계는 그 경계 또는 하위 도메인을 포함하는 모델이 잘못돼도 안전하게 해준다.
+
+바운디드 컨텍스트를 설계할 때는 경계를 넓게 해서 시작하는 것이 좋다. 나중에 필요에 따라 넓을 경계를 더 작은 여러 경계로 쪼갠다.
+
+일반 하위 도메인과 지원 하위 도메인은 모두 정형화되어 있고 변동성이 훨씬 적으므로 이 같은 휴리스틱은 주로 핵심 하위 도메인을 포함한 바운디드 컨텍스트에 적용된다.
+
+
+
+#### 비즈니스 로직 구현 패턴
+
+----
+
+트랜잭션 스크립트와 액티브 레코드 패턴은 둘 다 간단한 비즈니스 로직을 포함하는 하위 도메인에 적합하다.
+
+도메인 모델과 이벤트 소싱 도메인 모델은 복잡한 비즈니스 로직을 가진 핵심 하위 도메인에 적합하다.
+
+![image](https://user-images.githubusercontent.com/80652992/185721535-44741237-b255-47d7-afe9-4a23bf946334.png)
+
+비즈니스 로직과 그 자료구조의 복잡성에 따라 비즈니스 로직의 구현 패턴을 결정하는 것은 하위 도메인의 유형에 대한 가정을 검증하는 방법이다.
+
+
+
+#### 아키텍처 패턴
+
+---
+
+아키텍처 패턴이 의도한 비즈니스 로직 구현 패턴을 알면 쉽게 아키텍처 패턴을 선정할 수 있다.
+
+![image](https://user-images.githubusercontent.com/80652992/185721566-2e60cf4c-f5bc-451a-a357-ac844cc188e1.png)
+
+
+
+#### 테스트 전략
+
+---
+
+비즈니스 구현 패턴과 아키텍처 패턴의 모든 지식은 코드베이스의 테스트 전략을 선택할 때 휴리스틱으로써 활용할 수 있다.
+
+![image](https://user-images.githubusercontent.com/80652992/185721588-e28a14f8-1811-4511-9de9-2d59753f2dd0.png)
+
+엔드-투-앤드, 통합, 단위의 여러 가지 테스트 유형, 강조하는 유형에 따라 테스트 전략을 나눈다.
+
+##### 피라미드형 테스트
+
+고전적인 피라미드형 테스트 전략에서는 단위 테스트를 강조하고 통합 테스트는 별로 없으며, 엔드-투-엔드 테스트는 더더욱 없다.
+
+피라미드형 테스트는 애그리게이트와 밸류 오브젝트 도메인 모델 패턴을 모두 잘 지원한다. 즉, 두 도메인 모델 패턴은 모두 사실상 비즈니스 로직을 테스트하는 완벽한 단위다.
+
+##### 다이아몬드형 테스트
+
+다이아몬드형 테스트에서 가장 집중하는 유형은 통합 테스트다.
+
+액티브 레코드 패턴이 사용되면 시스템의 비즈니스 로직은 서비스 계층과 비즈니스 로직 계층에 흩어지므로 두 계층의 연동에 중점을 둔다면 다이아몬드형 테스트가 더 효과적인 선택이다.
+
+##### 역전된 피라미드형 테스트
+
+역전된 피라미드형 테스트 전략은 엔드-투-엔드 테스트에 가장 많이 집중한다. 즉 처음부터 끝까지 애플리케이션의 워크플로를 검증하는 것이ㅣ다.
+
+트랜잭션 스크립트 패턴을 구현한 코드베이스는 비즈니스 로직이 간단하고 계층의 수가 적으므로 이 테스트 전략이 시스템의 엔드-투-엔드 흐름을 검증하는 데 더 효과적이다.
+
+![image](https://user-images.githubusercontent.com/80652992/185721827-8b5c2f86-855d-4bae-96c5-45f250b3cef6.png)
+
+##### 전술적 설계 의사결정 트리
+
+---
+
+비즈니스 로직 패턴, 아키텍처 패턴, 테스트 전략에 관한 휴리스틱은 다음 전술적 설계 의사결정 트리로 합쳐서 요약할 수 있다.
+
+![image](https://user-images.githubusercontent.com/80652992/185721848-fa54230c-23e5-449b-a87d-dc732ff964a4.png)
+
+이처럼 하위 도메인의 유형을 식별하고 의사결정 트리를 참고하는 것은 필수적인 설계 의사결정을 위한 시작접이다.
+
+
+
+#### 결론
+
+---
+
+설계 의사결정을 내리는 것도 중요하지만, 더 중요한 것은 시간이 지나면서 과거의 의사결정이 여전히 유효한지를 검증하는 것이다.
+
+
+
+#### 느낀점
+
+---
+
+휴리스틱이라는 개념에 대해 잘 이해하게 되었다.