소프트웨어 아키텍처 The Hard Parts 2주차 - 이동현 #596
Conversation
dhlee3994
requested review from
GeunJuLEE,
TaeHyoungKwon,
benscookie,
chichoon,
jongfeel,
tttghost and
ymkim97
dhlee3994
added
2026
Software Architecture: The Hard Parts
|
우측에 있는 |
Summary of ChangesHello @dhlee3994, 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' 스터디 그룹을 위한 주차별 학습 자료를 추가합니다. 모놀리식 애플리케이션을 분해하는 다양한 전략과 컴포넌트 기반 분해 패턴에 대한 개인적인 정리 및 논의할 질문들을 포함하고 있어, 스터디 참여자들이 해당 주제에 대해 깊이 이해하고 토론하는 데 기여할 것입니다. 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. 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.
마지막 항목의 '구(구할 구)심/원(멀 원)심 커플링' 표기가 어색합니다. 한자의 훈음을 그대로 적으신 것으로 보여 가독성을 해칠 수 있습니다. 일반적인 용어인 '구심/원심 커플링'으로 수정하거나, 한자를 병기하여 '구심(求心)/원심(遠心) 커플링'으로 표기하는 것을 제안합니다.
| - 구(구할 구)심/원(멀 원)심 커플링 | |
| - 구심/원심 커플링 |
| 모놀리식 애플리케이션을 분해할 때 컴포넌트 눌러 펴기 패턴(고아 클래스는 새 리프 노드(컴포넌트)로 옮겨서 눌러 편다.)을 적용하라고 나와있는데, | ||
| 여러번 읽어봐도 "무조건 하라"는 뉘앙스인 것 같습니다. (책 전체적인 뉘앙스로 봐서는 아마 아닐 것 같긴하지만..) | ||
|
|
||
| 네임스페이스와 디렉토리 경로가 일치해야하는 언어를 사용하는 입장에서는 이게 오히려 캡슐화를 방해하기도 하고, | ||
| 구조를 한눈에 확인하기 어렵게 만들 수 있다고 생각합니다. | ||
|
|
||
| 다른 분들은 "컴포넌트 눌러 펴기 패턴" 부분을 읽고 어떻게 생각하셨는지 다양한 관점을 들어보고 싶습니다. |
There was a problem hiding this comment.
저는 사실 불편함 없이 읽고 이해 했었습니다.
영어 단어로는 flatten이라고 표현했는데, 말 그대로 평평하게 편다는 느낌을 줍니다.
네임스페이스 수직 구조에 있는데 공통 기능은 다른 컴포넌트로 빼거나 아무것도 없는 고아 클래스는 하나로 합치는 등의 과정을 설명한 거라, 컴포넌트 분해 방법의 하나로 설명한거라 이해했거든요.
음 이런 방법이 있다 정도로 이해하시면 어떨까 싶습니다.
| ## 논의 | ||
|
|
||
| 모놀리식 애플리케이션을 분해할 때 컴포넌트 눌러 펴기 패턴(고아 클래스는 새 리프 노드(컴포넌트)로 옮겨서 눌러 편다.)을 적용하라고 나와있는데, | ||
| 여러번 읽어봐도 "무조건 하라"는 뉘앙스인 것 같습니다. (책 전체적인 뉘앙스로 봐서는 아마 아닐 것 같긴하지만..) | ||
|
|
||
| 네임스페이스와 디렉토리 경로가 일치해야하는 언어를 사용하는 입장에서는 이게 오히려 캡슐화를 방해하기도 하고, | ||
| 구조를 한눈에 확인하기 어렵게 만들 수 있다고 생각합니다. | ||
|
|
||
| 다른 분들은 "컴포넌트 눌러 펴기 패턴" 부분을 읽고 어떻게 생각하셨는지 다양한 관점을 들어보고 싶습니다. |
There was a problem hiding this comment.
이전에 따로 인지하고 있지 않던 부분이라서, 좀 생소하게 느껴지긴 했습니다
기존 제 코드들을 한번 보니, 책에서 말하는 평탄화 작업을 의도해서 한곳도 있고, 아닌 곳도 있었습니다
제 개인적으로는 책에서 말하는 평탄화를 하는 의도와 어떤 혜택이 있는지 어느정도 이해 하다보니, 유용한 팁이라고 생각이 들었습니다
leaf 노드 폴더에 모든 실제 구현 파일들을 모아둠으로써, 구현 파일들은 반드시 leaf 노드에 존재한다는 일관성을 얻을 수 있고, leaf 노드에 존재하는 구현 파일들을 과 계층구조를 가지는 도메인으로 분류 해서 이해할 수 있기 때문에, 코드를 통해서 도메인을 어떻게 분류 하였고 계층화 하였는지도 이해하기 더 쉬워지지 않았나 라는 생각을 했습니다
늦어서 죄송합니다.