소프트웨어 아키텍처 the hard parts sprint 3 - 김종필 (#601)

* Add chapter 6 review

* Add chapter 7 review and discussion

* Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter6_Pulling_Apart_Operational_Data.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

* Fix comment link

* Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter7_Service_Granularity.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

---------

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Author: jongfeel

2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter6_Pulling_Apart_Operational_Data.md

@@ -0,0 +1,29 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1612
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1612#issuecomment-3831102227
+- https://github.com/jongfeel/BookReview/issues/1612#issuecomment-3841314191
+
+### Review content 1
+
+에릭 에반스의 도메인 주도 설계가 등장한다.
+이 책을 읽어 봤으므로 어떤 방향으로 데이터베이스를 나눠야 하는 것인지 이해가 조금은 된다.
+
+주의할 점은 이 책에서는 경계 콘텍스트로 번역했지만
+도메인 주도 설계의 번역은 제한된 콘텍스트라는 점이다.
+
+출판사, 번역가가 다르다 보니 이런 일이 생기는 건데
+헷갈려 하지 말고 원어인 bounded context를 기억하고 있는 것이 좋다고 본다.
+
+- https://github.com/jongfeel/BookReview/issues/897
+
+### Review content 2
+
+용어: synonym
+
+아마 오라클 데이터베이스를 쓸 때 알았을 수도 있지만, 현 시점에서는 처음 들어보는 용어이다.
+AI에게 물어보거나 검색해 보면 어떤 용도로 쓰는지 다시 복습할 수 있다.
+핵심 개념은 다른 데이터베이스를 참조하거나 다른 서버의 데이터베이스를 참조해서 쓰고 싶을 때 정의해서 사용하는 것이다.

2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter7_Service_Granularity.md

@@ -0,0 +1,22 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1615
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1615#issuecomment-3848250975
+
+### Review content 1
+
+객관적 기준의 필요
+
+이 챕터에서도 서비스 분해, 통합에 대해 주관적인 관점이 들어 있기 때문에 서비스를 분해하거나 합치는데 어려움이 있다고 했다.
+이전 챕터에서도 느낀 부분이지만 7장의 설명도 참 체계적이고 쉬우면서 객관적인 데이터를 볼 수 있게 하는 좋은 가이드를 준 것 같다.
+분석 후 객관적인 데이터를 통해 서비스를 분해할지 합칠지에 대한 결정을 하는 건 참으로 아키텍처 결정을 하는데 있어서 올바른 결정이라고 본다.
+
+### 논의 주제
+
+서비스 세분도의 분해인, 통합인의 쉽고 이해할 수 있는 설명에 감동받아
+과거 서비스의 세분도를 떠올려 봤을 때 이 책에서 설명한 분해인, 통합인에 해당됐던 것들이 있는지 얘기해 보면 좋을 것 같습니다.
+
+저의 경우는 인프라 관련 횡단 기능인 API 공통 로직에 비즈니스적인 요구사항의 기능을 조금씩 넣었고 그걸 계속 하나의 서비스로 유지했다가 나중에 분리하려고 하면서 이 책에서 설명하는 경계 콘텍스트를 나누지 못해 결국 분리를 하지 못한 경험이 있습니다.