[테크니컬 라이팅] 산초(나영서) 미션 완성본 제출합니다. #585
Open
+316
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
skylar1220
suggested changes
Nov 5, 2024
|
|
||
| --- | ||
|
|
||
| ## 첫 번째 설계 |
There was a problem hiding this comment.
섹션별로 목표, 구현순서 ~~ 로 전개되는 게 머릿속에 구조화가 잘 네요!
level4.md
Outdated
Comment on lines
84
to
87
| - 양방향 연관관계 존재, 동기화를 위해 연관관계 편의 메서드 작성 | ||
| - list 형식을 저장해야 할 때 @ElementCollection 어노테이션 사용 | ||
| - N:N 관계에 대해서는 중간 테이블 생성 | ||
| - repository 를 통해야 하는 검증을 제외한, 모든 검증 로직을 Domain이자 Entity 인 객체의 생성자에서 실행 |
There was a problem hiding this comment.
첫번째 섹션에서는 이런 부분에 '도메인 연관관계'와 같은 헤딩을 붙여줬던 것 같아서 통일하면 좋겠습니다~
| 변경의 전파를 최소화할 수 있는 설계를 생각해보게 되었습니다. | ||
| 그래서 저는 원래 외래키를 쓰지 않는 설계에 대해 회의적이었지만, | ||
| 이번 설계에서는 엔티티가 다른 엔티티를 직접 참조하기보다 그 아이디만 long 타입으로 가지고 있도록 설계했습니다. | ||
| 이렇게 설계하니 엔티티 사이에 명확한 경계가 생기는 듯 했습니다. |
There was a problem hiding this comment.
엔티티 사이에 경계가 생겼다는 게 어떤 의미이고, 이게 왜 좋은 건지 한 번에 이해가 가지 않는 것 같아요!
level4.md
Outdated
Comment on lines
192
to
200
| 객체 변경이 전파된다. | ||
| 조회 시, Lazy initialization 를 야기할 수 있다. | ||
| 이를 방지하기 위해 fetch 를 eager 로 설정해야 하는데, | ||
| 이렇게 되면 lazy loading 의 장점을 활용하지 못한다. | ||
| 또한 어떤것까지 eager 로 할지, lazy 로 할지에 대한 경계가 모호하다. | ||
| 간단한 조회에도 복잡한 join 문으로 성능이 저하된다. | ||
| 객체 그래프가 깊다면, 트랜잭션도 길어진다. | ||
| 트랜잭션이 길어지면 하나의 커넥션을 오래 사용하게 된다. | ||
| 연관된 객체의 생명주기가 다르다면, lock 을 걸어줘야 한다. |
There was a problem hiding this comment.
이 부분은 글머리표를 달아서 나열하는 게 더 좋을 부분처럼 느껴지네요~
| 트랜잭션이 길어지면 하나의 커넥션을 오래 사용하게 된다. | ||
| 연관된 객체의 생명주기가 다르다면, lock 을 걸어줘야 한다. | ||
| 예를들어 A가 B에 의존하는데, B는 A와 생명주기가 달라서 | ||
| A와 관계없이 수정, 삭제될 수 있다고 하자. |
level4.md
Outdated
| 하지만 모든 객체 참조를 없애진 않았고, 생명 주기를 같이 하는 객체는 참조하게 했습니다. | ||
| 예를 들어, 리뷰를 작성할 때 Review 객체 뿐 아니라 TextAnswer 이라는 객체도 같이 생성됩니다. | ||
| 조회를 할 때도 이들은 하나로 묶여 조회되며, 수정이나 삭제를 할 때도 함께합니다. | ||
| 이러한 객체들은 FetchType.EAGER, CascadeType.PERSIST 와 같은 속성을 통해 하나의 단위처럼 관리되게 해주었습니다. |
Comment on lines
+236
to
+244
| 2. 달라지는 요구사항에 따라서 우리 코드 또한 언제든 달라질 수 있다는 것을 배웠습니다. | ||
| 우리 팀은 초반에 꼼꼼히 코드리뷰 하고, 열심히 토론했었습니다. | ||
| 저 역시 저를 소개하는 문구가 ‘한 줄의 코드를 작성하더라도 의미를 담자’라고 할 정도로, 정성을 들여 코드를 짰었습니다. | ||
| 하지만 요구사항의 변경으로 그 코드 전체가 날라가는 경험을 하니.. | ||
| 사소한 것에 집착하지 않게 되었습니다. | ||
| 물론 코드를 대충 작성하겠다는 것은 절대 아닙니다. | ||
| 다만 너무 세부적인 것에 집중하느라 시간을 쓰지 말아야겠다는 생각입니다. | ||
|
|
||
| 3. 서비스는 동적으로 변화한다는 것을 배웠습니다. |
There was a problem hiding this comment.
순서상 이게 2번보다 먼저오는 게 어떨까요?
서비스가 동적이란 걸 깨달음 → 그에 따라 우리의 코드도 언제든 달라진다는 걸 배움
donghoony
reviewed
Nov 5, 2024
|
|
||
| ### 목표 : 핵심 기능을 빠르게 구현 | ||
|
|
||
| 우리 팀의 첫 목표는 핵심 기능을 빠르게 구현하는 것이었습니다. |
There was a problem hiding this comment.
우리 팀은 핵심 기능을 빠르게 구현하기 위해 노력했습니다
는 어떤가요?
There was a problem hiding this comment.
소제목인 '목표 : 핵심 기능을 빠르게 구현' 와 호응되는 지금이 더 적절하다 생각해서 이건 원본 그대로 가겠습니다 ㅎㅎ
| JPA 를 공부하며 ‘객체와 테이블의 페러다임 불일치 해소를 위한 것 : 연관관계’ 라고 배웠고, | ||
| 객체가 다른 객체를 참조(조합) 하는 것이 좋은 것이라고 생각했었습니다. | ||
| 그런데 변하지 않을 것이라 생각했던 도메인도 삭제가 되는 경험을 하니 | ||
| 변경의 전파를 최소화할 수 있는 설계를 생각해보게 되었습니다. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
도메인 설계에 대한 글을 작성했습니다.
초안에서 더 가독성을 높여봤습니다.