소프트웨어 아키텍처 the hard parts sprint 5 - 김종필

2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter10_Distributed_Data_Access.md

@@ -0,0 +1,19 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1631
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1631#issuecomment-3980056208
+
+### 데이터 도메인 패턴
+
+사실 복제 캐싱 패턴 까지만 해도 이론적으로도 맞는 빌드업 방향이고 이 다음이 마지막인데 더 좋은게 있다고? 라는 생각이 들었다.
+그리고 데이터 도메인 패턴을 보고 나서 든 생각은 다음의 두 가지였다.
+
+- 데이터 테이블을 정말 마이크로하게 쪼개는게 맞나?
+- 서비스간 통신에 의한 성능이나 내고장성 문제라면 마이크로서비스의 원칙과 도메인의 기준을 정말 잘 잡아야 하지 않을까?
+
+였다.
+
+Academic Conference에 참여하는 두 백엔드 개발자 분들인 태형님과 근주님의 경험적인 얘기가 이 책을 읽는데 많은 도움이 되고 있다.

2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter11_Managing_Distributed_Workflows.md

@@ -0,0 +1,13 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1632
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1632#issuecomment-3984800990
+
+### 오케스트레이션과 코레오그래피
+
+앞서 1장, 2장에서 아주 잠깐 소개 되었는데 그때 조금 찾아보고 이해했다면 이 챕터의 내용은 완벽 정리 챕터의 느낌이 강했다.
+용어의 정의, 구체적인 서비스 워크플로 예시, 장단점 및 트레이드 오프 설명까지 있어서
+앞으로 오케스트레이션과 코레오그래피 용어가 나온다면 이 챕터를 참고하면 좋을 것 같다.

2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter12_Transactional_Sagas.md

@@ -0,0 +1,30 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1635
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1635#issuecomment-3998087301
+
+### 전체적인 소감
+
+사가 패턴의 종류 운영 아키텍처의 특징이 잘 설명되어 있기 때문에
+자신의 운영 시스템에 대한 특성을 잘 파악해서 적용해 보면 될 것 같다.
+
+에픽, 폰 태그, 호러 스토리 사가는 특별한 이유가 없다면 선택하지 않는 쪽을 택하면 될 것 같고
+페어리 테일, 패러렐, 앤솔로지의 경우는 트랜잭션 보상이나 워크플로의 복잡도에 따라 선택해 보면 좋겠다는 생각이 든다.
+
+그리고 트랜잭션 사가라는 개념이 잘 정의된 하나를 결정해서 적용하는 방식이라고 생각했는데 그런건 아니고
+속성에 따라 어떻게 적용할지에 따라 다르다는 걸 책을 읽고 설명을 통해 알게 되었다.
+
+만약 사가 패턴을 언급하고 빠르게 참고해야 할 필요가 있다면 이 책의 챕터 12를 보면 좋겠다는 생각이 든다.
+
+### 논의 주제
+
+단순 워크플로라면 앤솔로지 사가가 가장 적합한 패턴이라는 생각이고 여기에 복잡한 워크플로가 추가되면 패러렐 사가 패턴이면 좋겠다는 생각이 든다.
+에픽 사가, 호러 스토리 사가 등은 피해야 할 사가 패턴인 것 같기도 한데
+
+사가 패턴을 만드는 아키텍처 속성 세 가지인 통신 방식, 일관성 방식, 조정 방식에서 가장 포기하고 싶지 않은 방식이나 선호하는 방식이 있다면 그 이유에 대해 얘기해 보면 좋을 것 같다.
+
+과거 운영팀과 개발팀이 함께 같은 조직으로 묶여 있던 회사에서 짧게 일했을 때 운영팀으로부터 받았던 비슷한 질문이기도 했다.
+나의 경우는 최종 일관성에 대한 워크플로만 명확하다면 트랜잭션 보상에 대해 크게 신경쓰지 않아도 돼서 좋을 것 같다는 입장이 강한 편이다.