소프트웨어 아키텍처 the hard parts sprint 3 - 김종필#601
Conversation
jongfeel
requested review from
GeunJuLEE,
TaeHyoungKwon,
benscookie,
chichoon,
dhlee3994,
tttghost and
ymkim97
jongfeel
added
2026
Software Architecture: The Hard Parts
|
우측에 있는 |
Summary of ChangesHello @jongfeel, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 이 PR은 "소프트웨어 아키텍처 the hard parts 2판"의 6장과 7장에 대한 저자의 요약 및 리뷰 노트를 추가합니다. 이 노트들은 데이터베이스 특성, 도메인 주도 설계의 바운디드 컨텍스트의 미묘한 차이, 그리고 마이크로서비스 아키텍처에서 서비스 세분도를 결정할 때 객관적인 기준의 중요성을 깊이 있게 다룹니다. 저자는 또한 각 장에서 얻은 개인적인 통찰력과 논의 주제를 공유합니다. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
안녕하세요, 김종필님. PR 잘 보았습니다. '소프트웨어 아키텍처 the hard parts' 6장과 7장에 대한 리뷰를 추가하셨네요. 책의 내용을 깊이 있게 이해하고 자신의 경험과 연결하여 정리한 점이 인상적입니다. 특히 서비스 분해 및 통합에 대한 객관적인 기준의 필요성을 강조하고, 과거 경험을 공유해주신 부분이 다른 분들에게도 큰 도움이 될 것 같습니다. 문서의 완성도를 높이기 위해 몇 가지 개선점을 제안드립니다.
...als_of_Software_Architecture_2nd_Edition/jongfeel/Chapter6_Pulling_Apart_Operational_Data.md
Outdated
Show resolved
Hide resolved
| - https://github.com/jongfeel/BookReview/issues/1612#issuecomment-3831102227 | ||
| - https://github.com/jongfeel/BookReview/issues/1612#issuecomment-3841314191 |
There was a problem hiding this comment.
7장(Service Granularity) 리뷰 파일에 6장(Pulling Apart Operational Data)의 리뷰 코멘트 링크(issue/1612)가 포함되어 있습니다. 이 파일의 주제인 7장 리뷰에 해당하는 issue/1615의 코멘트 링크로 수정하여 내용의 일관성을 높이는 것을 제안합니다.
2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter7_Service_Granularity.md
Outdated
Show resolved
Hide resolved
| 서비스 세분도의 분해인, 통합인의 쉽고 이해할 수 있는 설명에 감동받아 | ||
| 과거 서비스의 세분도를 떠올려 봤을 때 이 책에서 설명한 분해인, 통합인에 해당됐던 것들이 있는지 얘기해 보면 좋을 것 같습니다. | ||
|
|
||
| 저의 경우는 인프라 관련 횡단 기능인 API 공통 로직에 비즈니스적인 요구사항의 기능을 조금씩 넣었고 그걸 계속 하나의 서비스로 유지했다가 나중에 분리하려고 하면서 이 책에서 설명하는 경계 콘텍스트를 나누지 못해 결국 분리를 하지 못한 경험이 있습니다. No newline at end of file |
There was a problem hiding this comment.
책에 있는 모든 세분도 분해인을 직간접적으로 경험을 해보았는데, 그 중 일부만 소개드리면 아래와 같습니다
이전에 라이더 도메인 서버를 만들면서, 라이더의 배달을 전담하는 서버(A)와 라이더의 배달을 제외한 모든 것(정산, 입직, 보험처리, 운영업무 등)을 처리하는 서버(B)를 분리한적이 있었습니다
책에 나와있는 세분도 분해인의 기준으로볼 때, 확장성/처리량, 내고장성 과 관련이 있다고 말할 수 있을거 같습니다
확장성/처리량 의 측면
- B의 경우, 배달 외의 모든 도메인을 처리하기 때문에, 도메인 단위 확장을 고려해야 합니다
- A는 운행하는 라이더의 수가 늘어날 수록 영향을 받기 때문에, 트래픽 양상이 유동적 입니다. 반면에 B의 경우는 라이더의 운행과 상관없이 특정 도메인의 비즈니스 규칙에 따라 트래픽 양상이 상대적으로 덜 유동적 입니다
내고장성의 측면
- A의 경우 실시간적으로 라이더가 배달을 할 때 요청을 받는 서버이고, 이 배달을 무사히 완료하는게 회사의 수익과 직결하기 때문에 매우 크리티컬하다고 볼 수 있습니다. 반면에 B의 경우는 회사 내부 운영자 향 관리 및 외부사와 연동을 목적으로 하기 때문에, 상대적으로 덜 실시간적이고, 덜 크리티컬하다고 볼 수 있습니다. 이처럼 A와 B는 비즈니스 임팩트 측면에서 차이가 있기에 B의 어떤 기능으로 인해서 A가 영향을 받는 다면 비즈니스에 큰 타격을 입을 수 있기에, 내고장성을 고려하여 A,B를 나누었습니다
…l/Chapter6_Pulling_Apart_Operational_Data.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…l/Chapter7_Service_Granularity.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| ### 논의 주제 | ||
|
|
||
| 서비스 세분도의 분해인, 통합인의 쉽고 이해할 수 있는 설명에 감동받아 | ||
| 과거 서비스의 세분도를 떠올려 봤을 때 이 책에서 설명한 분해인, 통합인에 해당됐던 것들이 있는지 얘기해 보면 좋을 것 같습니다. |
There was a problem hiding this comment.
서로 다른 경로의 화면이지만 겹치는 로직 (공통 코드) 이 많고 레이아웃이 똑같아서 같은 서비스로 묶어서 개발했다가
기능이 복잡해짐에 따라 각 화면별 예외처리가 늘어나면서 결국 거대 모놀리스 덩어리가 된 적이 있습니다
지금 돌이켜보니 한두개의 통합인만 바라보고 통합하면 나중에 피본다는 귀중한 경험을 했네요
3 participants
NOTICE
다들 pull request의 제목을 주차로 적었는데 저희 모임은 2주 간격으로 진행됩니다.
따라서 산술적으로는 이번이 6주차가 맞는데 주차로 적으실 분은 그렇게 해도 되고 저는 sprint라는 단위를 쓰는게 좋다고 봐서 sprint로 바꿔서 쓰겠습니다.
Review
이번에도 여러 데이터베이스의 특성에 대해 알 수 있는 시간도 가져보고
마이크로 서비스라고 서비스를 무작정 나누지 말고 어떤 요인으로 나누고 통합해야 하는지 분석하는 방법을 또 친절하고 쉽게 알려줘서 이번에도 큰 감동을 받았습니다.
지금 새벽시간인데도 책을 끝까지 읽고 읽었던 내용을 다시 생각하게 만드는 힘이 있는 좋은 책인 것 같습니다.