소프트웨어 아키텍처 the hard parts sprint 5 - 김종필#619
Conversation
|
우측에 있는 |
Summary of ChangesHello, 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' 책의 10장, 11장, 12장에 대한 저자의 학습 내용을 문서화합니다. 분산 시스템 아키텍처의 핵심 개념인 분산 데이터 접근, 분산 워크플로우 관리, 트랜잭션 사가 패턴에 대한 이해를 정리하고, 저자의 개인적인 통찰과 질문을 공유하여 해당 주제에 대한 깊이 있는 탐구를 보여줍니다. 이를 통해 저자는 소프트웨어 아키텍처에 대한 전반적인 이해를 더욱 명확히 하고 있습니다. 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
|
There was a problem hiding this comment.
Code Review
이번 PR은 '소프트웨어 아키텍처의 어려운 부분들' 책의 10, 11, 12장에 대한 요약 문서를 추가하는 내용입니다. 전반적으로 각 챕터의 핵심 내용을 잘 정리해주셨습니다. 리뷰 중 몇 가지 사소한 개선점을 발견했습니다. 모든 마크다운 파일 끝에 개행 문자가 누락되어 있어 추가를 제안했으며, 가독성을 높이기 위해 일부 문장에서 문법적인 수정을 제안했습니다. 제안된 변경 사항들을 확인해 보시고 반영해 주시면 감사하겠습니다.
Note: Security Review has been skipped due to the limited scope of the PR.
...damentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter10_Distributed_Data_Access.md
Outdated
Show resolved
Hide resolved
...ls_of_Software_Architecture_2nd_Edition/jongfeel/Chapter11_Managing_Distributed_Workflows.md
Outdated
Show resolved
Hide resolved
.../Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter12_Transactional_Sagas.md
Outdated
Show resolved
Hide resolved
.../Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter12_Transactional_Sagas.md
Outdated
Show resolved
Hide resolved
…l/Chapter10_Distributed_Data_Access.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…l/Chapter11_Managing_Distributed_Workflows.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…l/Chapter12_Transactional_Sagas.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…l/Chapter12_Transactional_Sagas.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| ### 논의 주제 | ||
|
|
||
| 단순 워크플로라면 앤솔로지 사가가 가장 적합한 패턴이라는 생각이고 여기에 복잡한 워크플로가 추가되면 패러렐 사가 패턴이면 좋겠다는 생각이 든다. | ||
| 에픽 사가, 호러 스토리 사가 등은 피해야 할 사가 패턴인 것 같기도 한데 | ||
|
|
||
| 사가 패턴을 만드는 아키텍처 속성 세 가지인 통신 방식, 일관성 방식, 조정 방식에서 가장 포기하고 싶지 않은 방식이나 선호하는 방식이 있다면 그 이유에 대해 얘기해 보면 좋을 것 같다. | ||
|
|
||
| 과거 운영팀과 개발팀이 함께 같은 조직으로 묶여 있던 회사에서 짧게 일했을 때 운영팀으로부터 받았던 비슷한 질문이기도 했다. | ||
| 나의 경우는 최종 일관성에 대한 워크플로만 명확하다면 트랜잭션 보상에 대해 크게 신경쓰지 않아도 돼서 좋을 것 같다는 입장이 강한 편이다. |
There was a problem hiding this comment.
워낙 케이스가 다양하다보니, 일반화해서 딱 말하긴 힘든데 통신 방식의 경우는 요청에 대한 응답이 필요 없고, 비즈니스 로직 외의 부가적인 작업이라면, 비동기를 사용하고 그 외에는 동기를 사용하는쪽으로 합니다
일관성 방식은 어떤 비즈니스로직을 처리하느냐에 따라서, 최종 일관성으로 처리할지, 원자적 일관성으로 처리할지 매번 상황마다 판단을 다르게 하는거 같은데, 단순히 비즈니스 로직 뿐아니라, 팀의 레거시로 남아있는 관습이나 기존 설계 구조 등도 영향을 미치는거 같습니다
조정 방식은 저희 회사 기준으론, 팀 구조 대로 MS가 나뉘어 있고, 각각 책임 지는 형태로 되어있다보니, 자연스레 크레오그래피 기준으로만 MSA 를 구성 하고 있습니다
아마도, 조직구조가 계층 구조를 가지도록 변경되서, 전체 워크 플로우를 관장해서 처리하는 팀이 생긴 다면, 오케스트레이션도 생기지 않을까? 생각됩니다
마지막 스프린트를 남겨 둔 시점에서 점점 소프트웨어 아키텍처에 대한 이미지가 명확하게 정리되고 머리속에 자리잡혀 가는 느낌이 강하게 드네요.
읽기 전에는 어려울 것 같고 양이 많아서 귀찮아서 대충하면 안되는데 라는 불안감이 좀 있었는데
지금은 그런 불안한 감정 보다는 읽기 잘했다는 느낌이 더 강하게 자리잡고 있습니다.
Close #618