From 46a8fb3e24c1a10097c82d08a0c352efe63071e4 Mon Sep 17 00:00:00 2001 From: jongfeel Date: Wed, 7 Jan 2026 21:51:39 +0900 Subject: [PATCH 1/6] Software architecture, chater 1 to 3 review --- ...appens_When_There_Are_No_Best_Practices.md | 27 +++++++++++++++++++ ...rning_Coupling_in_Software_Architecture.md | 14 ++++++++++ .../Chapter3_Architectural_Modularity.md | 14 ++++++++++ 3 files changed, 55 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter3_Architectural_Modularity.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md new file mode 100644 index 00000000..e9cd5e20 --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md @@ -0,0 +1,27 @@ +## Summary + +- https://github.com/jongfeel/BookReview/issues/1576 + +## Review + +- https://github.com/jongfeel/BookReview/issues/1576#issuecomment-3705494790 + +### 1.4 ADR 에서 + +아키텍처 책이다 보니 ADR이 빠질 수 없는데, 나도 ADR를 실험적으로 몇 개의 문서를 작성해 관리해 봤다. +확실히 프로젝트 시작 부분에서 ADR 몇 개를 기록해 두니, 프로젝트 중반 이후에 왜? 라는 의문이 어느 정도 해소가 되는 경험을 했었다. + +처음엔 ADR에 대해 잘 이해를 못해서 아키텍처 결정이라기 보다는 어떤 기법에 대해 사용해야 하는가 말아야 하는가로 적은 적도 있다. +예) Singleton 패턴을 사용하지 말아야 하는 이유 + +하지만 아키텍처의 의사 결정이므로 아키텍처 초반에 결정해야 하는 것들에 대한 걸 적는 건 효과가 있긴 했다. +예) DI 플러그인에서 Zenject 대신 VContainer를 선택해야 하는 이유 +그래서 결정에 대한 이유를 적다 보니, 나중에 프로젝트 투입한 사람이나 처음부터 아키텍처 작업을 하지 않았던 사람도 왜? 라는 의문을 가질 때 쯤 ADR를 살펴보는 건 상당히 유용한 것 같고, 경험상 필요하다고 느껴졌다. + +어쩌면 초반 화면 설계 회의나 개발 논의 회의를 할 때 나온 내용을 회의록 처럼 적은 것들이 상당히 많이 있을 텐데 +거기에는 분명 의사결정에 대한 논의가 포함되어 있었을 것이고(팀장이 그냥 하자고 해서 없을 수도 있음) +그래서 결정을 한 것에 대한 기록을 조금 더 확실하게 파악하고 관리하기 위한 형태가 ADR이라고 이해하는게 좋다고 본다. + +## 논의 주제 + +아마 ADR을 처음 접하거나 들어본적 없는 분이 많을 텐데, 제 ADR 리뷰에 대해 라이브로 설명해 드리고 혹시 ADR을 작성해 본 분이 있다면 제 경험했던 효과와 다른 효과를 얻었는지에 대해 얘기해 보면 좋겠습니다. \ No newline at end of file diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md new file mode 100644 index 00000000..c9be69cf --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md @@ -0,0 +1,14 @@ +## Summary + +- https://github.com/jongfeel/BookReview/issues/1578 + +## Review + +- https://github.com/jongfeel/BookReview/issues/1578#issuecomment-3714443240 + +### 2.1.3 높은 정적 커플링에서 + +아키텍처 퀀텀이라는 용어는 이전에 봐왔던 아키텍처 책에서는 보지 못했던 생소한 용어인데 +다 읽고 나서 이해한 건 왜 마이크로서비스가 필요한지를 아키텍처 특성 관점에서 설명할 수 있다는 점이다. +여태까지 이해한건 작은 서비스를 만들면 응집도, 결합도 관점에서 설명이 가능했지만 이건 선호해야 하고 피해야 할 기능 관점에서의 설계 목표였지 아키텍처 특성의 레벨 까지는 아니었던 것 같다. +이제 마이크로서비스가 아키텍처 특성의 관점에서 필요한 이유에 대해 서비스 별 아키텍처 특성인 확장성, 보안 등을 별도 적용 범위를 가질 수 있다는 점에서 좋다고 얘기할 수 있게 됐다. diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter3_Architectural_Modularity.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter3_Architectural_Modularity.md new file mode 100644 index 00000000..59cc294b --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter3_Architectural_Modularity.md @@ -0,0 +1,14 @@ +## Summary + +- https://github.com/jongfeel/BookReview/issues/1579 + +## Review + +- https://github.com/jongfeel/BookReview/issues/1579#issuecomment-3718371662 + +### 3.1.2 시험성에서 + +서비스 별로 테스트 코드가 독립적이어야 하는 건 상식적이긴 한데 +책의 설명대로라면 서비스가 동적 연결 그러니까 2장에서 설명한 아키텍처 퀀텀의 통신에 있어서 커플링이 일어난다면 시험성이 떨어지는 건 막을 수 없다고 본다. +이런 상황일 때 내가 생각한 대안은 각 서비스 별로 다른 서비스에 의존적인 부분이 꼭 필요하다면 그 서비스의 mock을 만드는 것도 좋은 방법이라고 본다. +책의 그림에서는 서비스 B, C의 mock 2개를 만들어야 하는데 보통은 이상적인 커플링의 대상은 1개 이므로 커플링이 만들어지는 서비스의 mock을 만들면 시험성이 좋아질 것이라고 본다. \ No newline at end of file From 8481392e99f33b6a0ff27670920654d059a9c014 Mon Sep 17 00:00:00 2001 From: Kim Jong Feel Date: Wed, 7 Jan 2026 21:59:04 +0900 Subject: [PATCH 2/6] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../Chapter1_What_Happens_When_There_Are_No_Best_Practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md index e9cd5e20..a3fce79a 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md @@ -8,7 +8,7 @@ ### 1.4 ADR 에서 -아키텍처 책이다 보니 ADR이 빠질 수 없는데, 나도 ADR를 실험적으로 몇 개의 문서를 작성해 관리해 봤다. +아키텍처 책이다 보니 ADR이 빠질 수 없는데, 나도 ADR을 실험적으로 몇 개의 문서를 작성해 관리해 봤다. 확실히 프로젝트 시작 부분에서 ADR 몇 개를 기록해 두니, 프로젝트 중반 이후에 왜? 라는 의문이 어느 정도 해소가 되는 경험을 했었다. 처음엔 ADR에 대해 잘 이해를 못해서 아키텍처 결정이라기 보다는 어떤 기법에 대해 사용해야 하는가 말아야 하는가로 적은 적도 있다. From 2e034baf6236f452402041f746e088884ae61214 Mon Sep 17 00:00:00 2001 From: Kim Jong Feel Date: Wed, 7 Jan 2026 21:59:20 +0900 Subject: [PATCH 3/6] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../Chapter1_What_Happens_When_There_Are_No_Best_Practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md index a3fce79a..d0aebd98 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md @@ -16,7 +16,7 @@ 하지만 아키텍처의 의사 결정이므로 아키텍처 초반에 결정해야 하는 것들에 대한 걸 적는 건 효과가 있긴 했다. 예) DI 플러그인에서 Zenject 대신 VContainer를 선택해야 하는 이유 -그래서 결정에 대한 이유를 적다 보니, 나중에 프로젝트 투입한 사람이나 처음부터 아키텍처 작업을 하지 않았던 사람도 왜? 라는 의문을 가질 때 쯤 ADR를 살펴보는 건 상당히 유용한 것 같고, 경험상 필요하다고 느껴졌다. +그래서 결정에 대한 이유를 적다 보니, 나중에 프로젝트 투입한 사람이나 처음부터 아키텍처 작업을 하지 않았던 사람도 왜? 라는 의문을 가질 때쯤 ADR을 살펴보는 건 상당히 유용한 것 같고, 경험상 필요하다고 느껴졌다. 어쩌면 초반 화면 설계 회의나 개발 논의 회의를 할 때 나온 내용을 회의록 처럼 적은 것들이 상당히 많이 있을 텐데 거기에는 분명 의사결정에 대한 논의가 포함되어 있었을 것이고(팀장이 그냥 하자고 해서 없을 수도 있음) From 7f39ce8013a7dee60800a1d7eb451589b68c64a6 Mon Sep 17 00:00:00 2001 From: Kim Jong Feel Date: Wed, 7 Jan 2026 21:59:27 +0900 Subject: [PATCH 4/6] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../Chapter1_What_Happens_When_There_Are_No_Best_Practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md index d0aebd98..d8201c7d 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md @@ -24,4 +24,4 @@ ## 논의 주제 -아마 ADR을 처음 접하거나 들어본적 없는 분이 많을 텐데, 제 ADR 리뷰에 대해 라이브로 설명해 드리고 혹시 ADR을 작성해 본 분이 있다면 제 경험했던 효과와 다른 효과를 얻었는지에 대해 얘기해 보면 좋겠습니다. \ No newline at end of file +아마 ADR을 처음 접하거나 들어본 적 없는 분이 많을 텐데, 제 ADR 리뷰에 대해 라이브로 설명해 드리고 혹시 ADR을 작성해 본 분이 있다면 제 경험했던 효과와 다른 효과를 얻었는지에 대해 얘기해 보면 좋겠습니다. \ No newline at end of file From 7e040b75009eb73ee635b6428ef8082639b98824 Mon Sep 17 00:00:00 2001 From: Kim Jong Feel Date: Wed, 7 Jan 2026 21:59:49 +0900 Subject: [PATCH 5/6] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../Chapter2_Discerning_Coupling_in_Software_Architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md index c9be69cf..4c1df8b9 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md @@ -10,5 +10,5 @@ 아키텍처 퀀텀이라는 용어는 이전에 봐왔던 아키텍처 책에서는 보지 못했던 생소한 용어인데 다 읽고 나서 이해한 건 왜 마이크로서비스가 필요한지를 아키텍처 특성 관점에서 설명할 수 있다는 점이다. -여태까지 이해한건 작은 서비스를 만들면 응집도, 결합도 관점에서 설명이 가능했지만 이건 선호해야 하고 피해야 할 기능 관점에서의 설계 목표였지 아키텍처 특성의 레벨 까지는 아니었던 것 같다. +여태까지 이해한 건 작은 서비스를 만들면 응집도, 결합도 관점에서 설명이 가능했지만 이건 선호해야 하고 피해야 할 기능 관점에서의 설계 목표였지 아키텍처 특성의 레벨 까지는 아니었던 것 같다. 이제 마이크로서비스가 아키텍처 특성의 관점에서 필요한 이유에 대해 서비스 별 아키텍처 특성인 확장성, 보안 등을 별도 적용 범위를 가질 수 있다는 점에서 좋다고 얘기할 수 있게 됐다. From aa5d7ee187c2e4d7217ba00ff40a0b81369707d5 Mon Sep 17 00:00:00 2001 From: Kim Jong Feel Date: Wed, 7 Jan 2026 21:59:58 +0900 Subject: [PATCH 6/6] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../Chapter2_Discerning_Coupling_in_Software_Architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md index 4c1df8b9..1ee54670 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md @@ -11,4 +11,4 @@ 아키텍처 퀀텀이라는 용어는 이전에 봐왔던 아키텍처 책에서는 보지 못했던 생소한 용어인데 다 읽고 나서 이해한 건 왜 마이크로서비스가 필요한지를 아키텍처 특성 관점에서 설명할 수 있다는 점이다. 여태까지 이해한 건 작은 서비스를 만들면 응집도, 결합도 관점에서 설명이 가능했지만 이건 선호해야 하고 피해야 할 기능 관점에서의 설계 목표였지 아키텍처 특성의 레벨 까지는 아니었던 것 같다. -이제 마이크로서비스가 아키텍처 특성의 관점에서 필요한 이유에 대해 서비스 별 아키텍처 특성인 확장성, 보안 등을 별도 적용 범위를 가질 수 있다는 점에서 좋다고 얘기할 수 있게 됐다. +이제 마이크로서비스가 아키텍처 특성의 관점에서 필요한 이유에 대해 서비스 별 아키텍처 특성인 확장성, 보안 등을 별도 적용 범위를 가질 수 있다는 점에서 좋다고 얘기할 수 있게 됐다.