diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter8_Reuse_Pattern.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter8_Reuse_Pattern.md
new file mode 100644
index 00000000..a90720bd
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter8_Reuse_Pattern.md
@@ -0,0 +1,24 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1622
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1622#issuecomment-3921793581
+
+### 8.6 코드 재사용 예시와 가치에 대한 설명
+
+보험회사의 각자 다른 팀의 예시로 설명했는데 이 예시를 보고 든 내 생각은 이렇다.
+지금은 휴대폰 번호로 개인 인증을 하는 시대이고 다른 방법으로 인증을 한다고 해도 이름, 성별, 주민등록번호, 휴대폰 번호 등은 공통 고객 정보가 될 것이다.
+이 정보는 통합 고객 정보로 두고 각 팀별로 원하는 정보는 팀별 고객 데이터베이스에 두는 것이다.
+만약 다른 팀에서 고객 정보를 원한다면 이미 가입되어 있는 고객인지만 체크하고 이후 팀에 맞는 도메인 고객 정보는 그 팀에서 추가로 관리하는 방법으로 해도 될 것 같다는 생각이다.
+
+그러면 아키텍처적인 문제를 해결할 수 있다.
+
+1. 팀별 도메인과 시나리오는 팀별 고객 정보를 통해 처리할 수 있다.
+2. 아키텍처적인 취약점, 즉 한 팀이 고객 정보를 변경하면 모든 팀에 문제가 생기는 예시지만 내가 제안한 방법은 자신의 팀의 도메인에 맞는 고객 정보만 변경되는 것이다. 즉 공통 고객 정보는 최초 가입 이후에는 변경이 없다.
+
+이후 재사용 문제도 해결 가능하다.
+
+1. 추상화, 이미 공통 고객 정보로 추상화가 가능해진 상태가 되었다. 
+2. 변경 빈도, 이름, 성별, 주민등록번호, 전화번호는 거의 변경될 일이 없다. 그나마 변경 빈도가 있는 건 전화번호인데 한 사람이 평생 전화번호를 바꿀 일이 몇 번 있을까? (나의 경우라서 적절하진 않겠지만 최초 016에서 010으로 바꿀 때 한 번 빼고 전화번호를 변경한 일이 없다)
diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter9_Data_Ownership_and_Distributed_Transactions.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter9_Data_Ownership_and_Distributed_Transactions.md
new file mode 100644
index 00000000..a8297c08
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter9_Data_Ownership_and_Distributed_Transactions.md
@@ -0,0 +1,22 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1623
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1623#issuecomment-3921813903
+
+### 9.8.3 이벤트 기반 패턴
+
+이벤트 메시지를 처리하는 방법에 있어서 실패하면 어떻하지라는 생각은 읽기 전 부터 들긴 했는데
+지속 가능 구독자라는 기능도 흥미롭고 무엇보다도 수신자가 처리에 실패하면 데드 레터 큐라는 곳에 보낸다는 것도 합리적이라는 생각이 들었다.
+사실 이런 내용도 메시지 큐 관련 내용 찾아보면 나올텐데 책 내용을 읽으면서 자연스럽게 이해가 되면서 합리적이었다가 맞다고 볼 수 있을 것 같다.
+여태까지 읽어봤던 아키텍처 책에는 이런 설명은 구체적으로 나와있지 않았고 이걸 쓰는 게 맞고 특징이 무엇이고만 나와 있었기 때문이다.
+
+## 논의 내용
+
+9.8 최종 일관성 패턴을 설명하는 세가지 방법에서 오케스트레이티드 요청 기반 패턴과 이벤트 기반 패턴에서 에러 처리할 때 트랜잭션 보상도 문제가 생기면 사람이 해결해야 한다는 내용이 나와 있습니다.
+사실 제가 과거에 작업했던 내용을 떠올려 보면 제가 직접 롤백하는 쿼리를 비즈니스 로직 처리 레벨이 아니라 직접 쿼리 명령 실행 프로그램을 통해 쿼리를 만들어 두고 파일로 저장해 뒀다가 정말 직접 실행해서 에러 처리에 대한 롤백 업데이트를 했었습니다.
+
+이게 다른 분들한테도 흔하게 있는 일인지 궁금하네요.
+흔하게 있는 일이라면 사람이 에러 처리하는 방법이 임시적인 방법이 아니라 얼마나 체계적이었는지도 얘기해 보면 좋겠습니다.
\ No newline at end of file