diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/donghyeon/week6.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/donghyeon/week6.md
new file mode 100644
index 00000000..f52cbe27
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/donghyeon/week6.md
@@ -0,0 +1,52 @@
+# 13 ~ 15장
+
+## 논의
+
+컨슈머가 실제로 쓰지 않는 데이터까지 같이 내려주는 걸 어디까지 허용할 것인가에 대해 논의하면 좋을 것 같습니다.
+
+예를 들어 Consumer A는 id, name이 필요하고, Consumer B는 id, name, description이 필요한 경우,  
+하나의 공통 계약으로 유지하는 것이 맞을지, 아니면 Consumer별 계약으로 분리하는 것이 맞을지 이야기하면 좋을 것 같습니다.
+
+### 내 생각
+
+기본적으로 별도의 계약으로 분리하는 것을 원칙으로 하되,  
+데이터가 특정 유스케이스에 종속되지 않고 **공통 개념**으로 볼 수 있다면 하나의 계약을 고려해 볼 수 있을 것 같습니다. 
+
+이커머스 도메인으로 예를 들어보겠습니다.
+
+- 주문 서비스: 주문자 이름
+- 리뷰 서비스: 작성자 이름, 프로필 이미지
+- 알림 서비스: 사용자 이름
+
+이 경우에는 모두 "사용자 정보"라는 공통 개념이기 때문에 하나의 공통 계약으로 유지하는 것을 고려할 수 있을 것 같습니다.  
+
+하지만 리뷰 서비스에 '작성자의 전체 리뷰 수', '작성자의 평균 별점'과 같은 특정 유스케이스에 종속된 데이터가 포함되기 시작한다면,     
+별도의 계약으로 분리하는 것이 좋을 것 같습니다.
+
+## 내용
+
+- 계약(Contract): 종류가 다른 아키텍처 파트가 어떻게 연결되는지 정의한 것
+  - 엄격한 계약: XML, 스키마 정보가 추가된 JSON, (g)RPC
+    - 장점: 계약 충실도 보장, 쉬운 검증 가능, 문서화 용이, 버저닝
+    - 단점: 단단한 커플링, 버저닝
+  - 중간 계약: GraphQL, REST
+  - 느슨한 계약: 단순 JSON, 가치 주도 계약, Map
+    - 장점: 고도의 디커프링, 발전성
+    - 단점: 계약 관리와 이를 해결하기 위한 피트니스 함수의 필요성
+  - **컨슈머 주도 계약**
+  - 스탬프 커플링: 오가는 데이터 중 극히 일부만 사용하는 경우 
+- 분석 데이터 관리
+  - 데이터 레이크(Data Lake): 모델을 적재 후 변환
+    - 장점: 데이터 웨어하우스 패턴보다 데이터 구조가 자유로움, 사전 변환 작업이 별로 없음, 분산 아키텍처에 어울림
+    - 단점: 관계를 파악하기 어려울 때가 많음, 그때그때 변환이 필요
+  - 데이터 메시(Data Mesh): 분석 데이터를 **탈중앙화**하여 각 도메인 팀이 직접 관리
+    - 장점: MSA와 궁합이 좋음, 분석 데이터와 운영 데이터의 우수한 디커플링
+    - 단점: 데이터 프로덕트 퀀텀과 계약 조정이 필요, 비동기 통신과 최종 일관성이 필요
+- 트레이드오프 분석 3단계
+  - 어느 파트가 서로 관련돼 있는지 확인
+  - 어떻게 서로 결합돼 있는지 분석
+  - 상호 의존적 시스템의 변경 영향도를 파악함으로써 트레이드오프 평가
+    - 정성적 분석 / 정량적 분석
+    - MECE(상호 배제와 전체 포괄) 리스트
+    - '컨텍스트 왜곡' 함정 주의: 부가 컨텍스트를 함께 고려
+    - 모델과 연관된 도메인 케이스