feat: 문서 구조 변경 및 tech-visual 스킬 추가
This commit is contained in:
DongHyeonka
@@ -0,0 +1,329 @@
|
||||
- generic [ref=f91e3]:
|
||||
- link "본문으로 건너뛰기" [ref=f91e4] [cursor=pointer]:
|
||||
- /url: "#main-content"
|
||||
- banner [ref=f91e5]:
|
||||
- generic [ref=f91e6]:
|
||||
- link "TechLog Studio" [ref=f91e7] [cursor=pointer]:
|
||||
- /url: /studio
|
||||
- text: TechLog
|
||||
- generic [ref=f91e8]: Studio
|
||||
- navigation "Studio 주 탐색" [ref=f91e10]:
|
||||
- link "작업본" [ref=f91e11] [cursor=pointer]:
|
||||
- /url: /studio/documents
|
||||
- link "게시 기록" [ref=f91e12] [cursor=pointer]:
|
||||
- /url: /studio/publications
|
||||
- link "새 문서" [ref=f91e13] [cursor=pointer]:
|
||||
- /url: /studio/documents/new
|
||||
- link "주제·프로젝트" [ref=f91e14] [cursor=pointer]:
|
||||
- /url: /studio/taxonomy
|
||||
- link "릴리즈" [ref=f91e15] [cursor=pointer]:
|
||||
- /url: /studio/releases
|
||||
- link "공개 사이트 보기" [ref=f91e16] [cursor=pointer]:
|
||||
- /url: /
|
||||
- button "로그아웃" [ref=f91e17]
|
||||
- main [ref=f91e18]:
|
||||
- generic [ref=f91e19]:
|
||||
- generic [ref=f91e20]:
|
||||
- region [ref=f91e21]:
|
||||
- generic [ref=f91e22]:
|
||||
- paragraph [ref=f91e23]: PROJECT_DECISION · VERSION 1
|
||||
- heading "문서 편집" [level=1] [ref=f91e24]
|
||||
- paragraph [ref=f91e25]: Query Strategy는 FeedQueryPort 뒤에서 소유한다
|
||||
- region [ref=f91e26]:
|
||||
- generic [ref=f91e27]:
|
||||
- paragraph [ref=f91e28]: DOCUMENT
|
||||
- heading "기본 정보" [level=2] [ref=f91e29]
|
||||
- generic [ref=f91e30]:
|
||||
- generic [ref=f91e31]:
|
||||
- generic [ref=f91e32]: 제목
|
||||
- textbox "제목" [ref=f91e33]: Query Strategy는 FeedQueryPort 뒤에서 소유한다
|
||||
- generic [ref=f91e34]:
|
||||
- generic [ref=f91e35]: slug
|
||||
- textbox "slug" [ref=f91e36]:
|
||||
- /placeholder: 비우면 제목에서 만듭니다 (영문 소문자·숫자·하이픈)
|
||||
- text: query-strategy-behind-port
|
||||
- generic [ref=f91e37]:
|
||||
- generic [ref=f91e38]: 요약
|
||||
- textbox "요약" [ref=f91e39]: 조회 전략은 퍼시스턴스 어댑터의 책임으로 둔다. 상위 계층에는 조회 조건과 반환 형태만 드러내고 fetch join, 배치, 프로젝션, 윈도우 함수 중 무엇을 쓰는지는 포트 뒤에 감춘다.
|
||||
- generic [ref=f91e40]: 목록 카드에는 약 90자까지 보입니다 · 104 / 2000
|
||||
- generic [ref=f91e41]:
|
||||
- generic [ref=f91e42]: Topic
|
||||
- combobox "Topic" [ref=f91e43]:
|
||||
- option "선택하지 않음"
|
||||
- option "JPA 피드 조회 성능" [selected]
|
||||
- option "OAuth/OIDC 인증 경계"
|
||||
- generic [ref=f91e44]:
|
||||
- generic [ref=f91e45]: Project
|
||||
- combobox "Project" [ref=f91e46]:
|
||||
- option "미지정"
|
||||
- option "Backend Clean Architecture"
|
||||
- option "KeyCloak Patterns"
|
||||
- option "Liner N + 1문제" [selected]
|
||||
- status [ref=f91e47]
|
||||
- group "근거 기록" [ref=f91e48]:
|
||||
- generic [ref=f91e50]:
|
||||
- generic [ref=f91e51]:
|
||||
- generic [ref=f91e52]: 근거 1 대상
|
||||
- combobox "근거 1 대상" [ref=f91e53]:
|
||||
- option "대상 선택"
|
||||
- option
|
||||
- option
|
||||
- option [disabled]
|
||||
- option
|
||||
- option
|
||||
- option
|
||||
- option "실제 동시 트래픽에서도 이 구조가 안정적인가"
|
||||
- option "서버 세션 기반 인증 구조는 다중 인스턴스에서 어떻게 운영할 것인가"
|
||||
- option "ANALYZE 이후 Cardinality Estimate는 어떻게 달라지는가"
|
||||
- option "Authorization Code Flow의 Endpoint와 Credential 이동 기준"
|
||||
- option "Authorization Code와 PKCE가 보호하는 구간"
|
||||
- option "Bearer JWT가 인증된 principal이 되기까지"
|
||||
- option "BFF 인증 구조 설계 기준"
|
||||
- option "BFF가 OAuth Token을 관리하는 조건"
|
||||
- option "BFF의 Session과 OAuth2AuthorizedClient를 어디에 저장할 것인가"
|
||||
- option "Browser Token을 없애면서 BFF에 Session과 CSRF 책임이 생긴 과정"
|
||||
- option "Collection Fetch Join Pagination의 In-memory Paging" [disabled]
|
||||
- option "Cookie로 인증하는 요청에서 CSRF token이 하는 일"
|
||||
- option "브라우저가 credential을 보관하는 위치와 그 성질"
|
||||
- option "DTO 변환 과정에서 발생한 Highlight 컬렉션 N+1"
|
||||
- option "필드 접근 없이 발생한 EAGER ToOne N+1"
|
||||
- option "Feed Visibility Query Pattern"
|
||||
- option "feed_visible을 Production CQRS로 승격할 것인가"
|
||||
- option "Fetch Join · Batch · Projection 선택 기준" [selected]
|
||||
- option "Fetch Join으로 N+1을 해결하다 만난 MultiBag과 행 폭증"
|
||||
- option "Fetch Type과 Fetch Strategy 구분"
|
||||
- option "Forward-Auth 구조에서 Application Authorization을 어디까지 Edge에 둘 것인가"
|
||||
- option "Forward-Auth에서 Client가 보낸 Identity Header를 신뢰하면 안 되는 이유"
|
||||
- option "Forward-Auth에서 Identity Header를 신뢰하기 위한 조건"
|
||||
- option "Forward-Auth와 Nginx auth_request의 동작"
|
||||
- option "Highlight 없는 FeedItem을 허용할 것인가"
|
||||
- option "외부 IdP와의 연동이라도 별도의 인증 방식이 아니다."
|
||||
- option "외부 IdP 연동과 Application 인증 구조의 경계"
|
||||
- option "외부 IdP Brokering의 동작"
|
||||
- option "JPA N+1 정량 진단 기준"
|
||||
- option "Keyset Pagination 설계 기준"
|
||||
- option "OAuth/OIDC 인증 패턴 선택 기준"
|
||||
- option "OAuth Token과 Application Session을 구분하는 기준"
|
||||
- option "PostgreSQL Query Plan 측정 기준"
|
||||
- option "Projection 이후에도 1,509행을 읽은 Row Over-fetch"
|
||||
- option "Public Client와 Confidential Client 구분 기준"
|
||||
- option "Query Plan은 실제 PostgreSQL에서 측정한다"
|
||||
- option "Refresh Token 관리만 서버로 이전, Access Token은 여전히 Browser에 노출"
|
||||
- option "Refresh Token Rotation과 다중 Replica 경쟁을 어떻게 처리할 것인가"
|
||||
- option "Round Trip과 Row Volume을 독립 측정할 것인가"
|
||||
- option "SPA에서 토큰을 직접 관리하면서 드러난 Browser Credential 경계"
|
||||
- option "Top-N-per-group 선택 기준"
|
||||
- option "Visibility OR이 Keyset Index를 깨뜨린 문제"
|
||||
- generic [ref=f91e54]:
|
||||
- generic [ref=f91e55]: 근거 1 이유
|
||||
- textbox "근거 1 이유" [ref=f91e56]: 포트 뒤에서 교체한 전략들의 선택 기준이다.
|
||||
- generic [ref=f91e57]:
|
||||
- button "위로" [disabled] [ref=f91e58]
|
||||
- button "아래로" [ref=f91e59]
|
||||
- button "삭제" [ref=f91e60]
|
||||
- generic [ref=f91e61]:
|
||||
- generic [ref=f91e62]:
|
||||
- generic [ref=f91e63]: 근거 2 대상
|
||||
- combobox "근거 2 대상" [ref=f91e64]:
|
||||
- option "대상 선택"
|
||||
- option
|
||||
- option
|
||||
- option [disabled]
|
||||
- option
|
||||
- option
|
||||
- option
|
||||
- option "실제 동시 트래픽에서도 이 구조가 안정적인가"
|
||||
- option "서버 세션 기반 인증 구조는 다중 인스턴스에서 어떻게 운영할 것인가"
|
||||
- option "ANALYZE 이후 Cardinality Estimate는 어떻게 달라지는가"
|
||||
- option "Authorization Code Flow의 Endpoint와 Credential 이동 기준"
|
||||
- option "Authorization Code와 PKCE가 보호하는 구간"
|
||||
- option "Bearer JWT가 인증된 principal이 되기까지"
|
||||
- option "BFF 인증 구조 설계 기준"
|
||||
- option "BFF가 OAuth Token을 관리하는 조건"
|
||||
- option "BFF의 Session과 OAuth2AuthorizedClient를 어디에 저장할 것인가"
|
||||
- option "Browser Token을 없애면서 BFF에 Session과 CSRF 책임이 생긴 과정"
|
||||
- option "Collection Fetch Join Pagination의 In-memory Paging" [selected]
|
||||
- option "Cookie로 인증하는 요청에서 CSRF token이 하는 일"
|
||||
- option "브라우저가 credential을 보관하는 위치와 그 성질"
|
||||
- option "DTO 변환 과정에서 발생한 Highlight 컬렉션 N+1"
|
||||
- option "필드 접근 없이 발생한 EAGER ToOne N+1"
|
||||
- option "Feed Visibility Query Pattern"
|
||||
- option "feed_visible을 Production CQRS로 승격할 것인가"
|
||||
- option "Fetch Join · Batch · Projection 선택 기준" [disabled]
|
||||
- option "Fetch Join으로 N+1을 해결하다 만난 MultiBag과 행 폭증"
|
||||
- option "Fetch Type과 Fetch Strategy 구분"
|
||||
- option "Forward-Auth 구조에서 Application Authorization을 어디까지 Edge에 둘 것인가"
|
||||
- option "Forward-Auth에서 Client가 보낸 Identity Header를 신뢰하면 안 되는 이유"
|
||||
- option "Forward-Auth에서 Identity Header를 신뢰하기 위한 조건"
|
||||
- option "Forward-Auth와 Nginx auth_request의 동작"
|
||||
- option "Highlight 없는 FeedItem을 허용할 것인가"
|
||||
- option "외부 IdP와의 연동이라도 별도의 인증 방식이 아니다."
|
||||
- option "외부 IdP 연동과 Application 인증 구조의 경계"
|
||||
- option "외부 IdP Brokering의 동작"
|
||||
- option "JPA N+1 정량 진단 기준"
|
||||
- option "Keyset Pagination 설계 기준"
|
||||
- option "OAuth/OIDC 인증 패턴 선택 기준"
|
||||
- option "OAuth Token과 Application Session을 구분하는 기준"
|
||||
- option "PostgreSQL Query Plan 측정 기준"
|
||||
- option "Projection 이후에도 1,509행을 읽은 Row Over-fetch"
|
||||
- option "Public Client와 Confidential Client 구분 기준"
|
||||
- option "Query Plan은 실제 PostgreSQL에서 측정한다"
|
||||
- option "Refresh Token 관리만 서버로 이전, Access Token은 여전히 Browser에 노출"
|
||||
- option "Refresh Token Rotation과 다중 Replica 경쟁을 어떻게 처리할 것인가"
|
||||
- option "Round Trip과 Row Volume을 독립 측정할 것인가"
|
||||
- option "SPA에서 토큰을 직접 관리하면서 드러난 Browser Credential 경계"
|
||||
- option "Top-N-per-group 선택 기준"
|
||||
- option "Visibility OR이 Keyset Index를 깨뜨린 문제"
|
||||
- generic [ref=f91e65]:
|
||||
- generic [ref=f91e66]: 근거 2 이유
|
||||
- textbox "근거 2 이유" [ref=f91e67]: 전략을 바꿔 가며 실패를 격리한 기록이다.
|
||||
- generic [ref=f91e68]:
|
||||
- button "위로" [ref=f91e69]
|
||||
- button "아래로" [ref=f91e70]
|
||||
- button "삭제" [ref=f91e71]
|
||||
- generic [ref=f91e72]:
|
||||
- generic [ref=f91e73]:
|
||||
- generic [ref=f91e74]: 근거 3 대상
|
||||
- combobox "근거 3 대상" [ref=f91e75]:
|
||||
- option "대상 선택"
|
||||
- option
|
||||
- option
|
||||
- option [selected]
|
||||
- option
|
||||
- option
|
||||
- option
|
||||
- option "실제 동시 트래픽에서도 이 구조가 안정적인가"
|
||||
- option "서버 세션 기반 인증 구조는 다중 인스턴스에서 어떻게 운영할 것인가"
|
||||
- option "ANALYZE 이후 Cardinality Estimate는 어떻게 달라지는가"
|
||||
- option "Authorization Code Flow의 Endpoint와 Credential 이동 기준"
|
||||
- option "Authorization Code와 PKCE가 보호하는 구간"
|
||||
- option "Bearer JWT가 인증된 principal이 되기까지"
|
||||
- option "BFF 인증 구조 설계 기준"
|
||||
- option "BFF가 OAuth Token을 관리하는 조건"
|
||||
- option "BFF의 Session과 OAuth2AuthorizedClient를 어디에 저장할 것인가"
|
||||
- option "Browser Token을 없애면서 BFF에 Session과 CSRF 책임이 생긴 과정"
|
||||
- option "Collection Fetch Join Pagination의 In-memory Paging" [disabled]
|
||||
- option "Cookie로 인증하는 요청에서 CSRF token이 하는 일"
|
||||
- option "브라우저가 credential을 보관하는 위치와 그 성질"
|
||||
- option "DTO 변환 과정에서 발생한 Highlight 컬렉션 N+1"
|
||||
- option "필드 접근 없이 발생한 EAGER ToOne N+1"
|
||||
- option "Feed Visibility Query Pattern"
|
||||
- option "feed_visible을 Production CQRS로 승격할 것인가"
|
||||
- option "Fetch Join · Batch · Projection 선택 기준" [disabled]
|
||||
- option "Fetch Join으로 N+1을 해결하다 만난 MultiBag과 행 폭증"
|
||||
- option "Fetch Type과 Fetch Strategy 구분"
|
||||
- option "Forward-Auth 구조에서 Application Authorization을 어디까지 Edge에 둘 것인가"
|
||||
- option "Forward-Auth에서 Client가 보낸 Identity Header를 신뢰하면 안 되는 이유"
|
||||
- option "Forward-Auth에서 Identity Header를 신뢰하기 위한 조건"
|
||||
- option "Forward-Auth와 Nginx auth_request의 동작"
|
||||
- option "Highlight 없는 FeedItem을 허용할 것인가"
|
||||
- option "외부 IdP와의 연동이라도 별도의 인증 방식이 아니다."
|
||||
- option "외부 IdP 연동과 Application 인증 구조의 경계"
|
||||
- option "외부 IdP Brokering의 동작"
|
||||
- option "JPA N+1 정량 진단 기준"
|
||||
- option "Keyset Pagination 설계 기준"
|
||||
- option "OAuth/OIDC 인증 패턴 선택 기준"
|
||||
- option "OAuth Token과 Application Session을 구분하는 기준"
|
||||
- option "PostgreSQL Query Plan 측정 기준"
|
||||
- option "Projection 이후에도 1,509행을 읽은 Row Over-fetch"
|
||||
- option "Public Client와 Confidential Client 구분 기준"
|
||||
- option "Query Plan은 실제 PostgreSQL에서 측정한다"
|
||||
- option "Refresh Token 관리만 서버로 이전, Access Token은 여전히 Browser에 노출"
|
||||
- option "Refresh Token Rotation과 다중 Replica 경쟁을 어떻게 처리할 것인가"
|
||||
- option "Round Trip과 Row Volume을 독립 측정할 것인가"
|
||||
- option "SPA에서 토큰을 직접 관리하면서 드러난 Browser Credential 경계"
|
||||
- option "Top-N-per-group 선택 기준"
|
||||
- option "Visibility OR이 Keyset Index를 깨뜨린 문제"
|
||||
- generic [ref=f91e76]:
|
||||
- generic [ref=f91e77]: 근거 3 이유
|
||||
- textbox "근거 3 이유" [ref=f91e78]: 같은 포트 뒤에서 구현을 바꾼 결정이다.
|
||||
- generic [ref=f91e79]:
|
||||
- button "위로" [ref=f91e80]
|
||||
- button "아래로" [disabled] [ref=f91e81]
|
||||
- button "삭제" [ref=f91e82]
|
||||
- button "근거 추가" [ref=f91e83]
|
||||
- region [ref=f91e84]:
|
||||
- generic [ref=f91e85]:
|
||||
- paragraph [ref=f91e86]: PROJECT DECISION
|
||||
- heading "프로젝트 결정" [level=2] [ref=f91e87]
|
||||
- generic [ref=f91e88]:
|
||||
- generic [ref=f91e89]:
|
||||
- generic [ref=f91e90]: 결정 상태
|
||||
- combobox "결정 상태" [ref=f91e91]:
|
||||
- option "아직 정하지 않음"
|
||||
- option "PROPOSED"
|
||||
- option "ADOPTED" [selected]
|
||||
- generic [ref=f91e92]:
|
||||
- generic [ref=f91e93]: 결정일
|
||||
- textbox "결정일" [ref=f91e94]
|
||||
- generic [ref=f91e95]:
|
||||
- generic [ref=f91e96]: 결정문
|
||||
- textbox "결정문" [ref=f91e97]: 조회 경로는 컨트롤러에서 유스케이스를 거쳐 조회 포트로 이어지고, 퍼시스턴스 어댑터가 그 포트를 구현한다. 조회 전략의 변경은 어댑터 안에서 끝낸다. 포트는 엔티티 타입을 노출하지 않는다. 컨트롤러는 엔티티를 의존하거나 반환하지 않는다.
|
||||
- generic [ref=f91e98]:
|
||||
- generic [ref=f91e99]: 판단 이유
|
||||
- textbox "판단 이유" [ref=f91e100]: 이 프로젝트에서 조회 전략을 여섯 번 바꿨다. 엔티티 매핑, fetch join, 배치, 프로젝션, 윈도우와 LATERAL, 커서 페이징이다. 전략마다 SQL 형태와 반환 구조가 달랐다. 전략이 상위 계층에 드러나 있었다면 매번 유스케이스와 웹 계층까지 함께 고쳐야 했다. 포트 뒤에 두었기 때문에 상위 계층은 그대로 두고 어댑터만 바꿔 가며 비교할 수 있었다. 엔티티 연관 게터를 좁게 열어 둔 것도 같은 경계다. 연관 게터가 열려 있으면 상위 계층이 객체 그래프를 타고 다니며 지연 로딩을 아무 데서나 촉발하거나 영속성 컨텍스트에 의존하게 된다. 포트가 엔티티를 노출하지 않으면 조회 방식이 바뀌어도 계약이 유지된다.
|
||||
- group "영향" [ref=f91e101]:
|
||||
- generic [ref=f91e103]:
|
||||
- generic [ref=f91e104]:
|
||||
- generic [ref=f91e105]: 영향 1
|
||||
- textbox "영향 1" [ref=f91e106]: 어댑터 안에 네이티브 SQL이 들어간다. 표준 JPQL로 표현되지 않는 윈도우 함수와 LATERAL을 써야 하기 때문이다. 이 코드는 포트 뒤에 머문다.
|
||||
- generic [ref=f91e107]:
|
||||
- button "위로" [disabled] [ref=f91e108]
|
||||
- button "아래로" [ref=f91e109]
|
||||
- button "삭제" [ref=f91e110]
|
||||
- generic [ref=f91e111]:
|
||||
- generic [ref=f91e112]:
|
||||
- generic [ref=f91e113]: 영향 2
|
||||
- textbox "영향 2" [ref=f91e114]: 반환 형태를 바꾸려면 포트 계약을 바꿔야 한다. 화면 요구가 바뀌면 계약도 함께 바뀐다.
|
||||
- generic [ref=f91e115]:
|
||||
- button "위로" [ref=f91e116]
|
||||
- button "아래로" [ref=f91e117]
|
||||
- button "삭제" [ref=f91e118]
|
||||
- generic [ref=f91e119]:
|
||||
- generic [ref=f91e120]:
|
||||
- generic [ref=f91e121]: 영향 3
|
||||
- textbox "영향 3" [ref=f91e122]: 전략별 실패를 프로덕션 코드에 섞지 않고 통합 테스트에 격리할 수 있었다. 다음 단계와 전후를 같은 기준으로 비교하는 데 필요했다.
|
||||
- generic [ref=f91e123]:
|
||||
- button "위로" [ref=f91e124]
|
||||
- button "아래로" [ref=f91e125]
|
||||
- button "삭제" [ref=f91e126]
|
||||
- generic [ref=f91e127]:
|
||||
- generic [ref=f91e128]:
|
||||
- generic [ref=f91e129]: 영향 4
|
||||
- textbox "영향 4" [ref=f91e130]: 어댑터가 조회 성능의 책임을 모두 가진다. 성능 문제의 원인을 찾을 때 이 경계 안을 먼저 본다.
|
||||
- generic [ref=f91e131]:
|
||||
- button "위로" [ref=f91e132]
|
||||
- button "아래로" [ref=f91e133]
|
||||
- button "삭제" [ref=f91e134]
|
||||
- generic [ref=f91e135]:
|
||||
- generic [ref=f91e136]:
|
||||
- generic [ref=f91e137]: 영향 5
|
||||
- textbox "영향 5" [ref=f91e138]: 경계를 지키는 검사를 자동화해야 한다. 포트가 엔티티를 노출하지 않는지, 의존 방향이 맞는지 확인하는 검사가 필요하다.
|
||||
- generic [ref=f91e139]:
|
||||
- button "위로" [ref=f91e140]
|
||||
- button "아래로" [disabled] [ref=f91e141]
|
||||
- button "삭제" [ref=f91e142]
|
||||
- button "영향 추가" [ref=f91e143]
|
||||
- region [ref=f91e144]:
|
||||
- generic [ref=f91e145]:
|
||||
- paragraph [ref=f91e146]: LIVE
|
||||
- heading "즉시 미리보기" [level=2] [ref=f91e147]
|
||||
- alert [ref=f91e149]:
|
||||
- heading "초안을 미리 볼 수 없습니다" [level=2] [ref=f91e150]
|
||||
- list [ref=f91e151]:
|
||||
- listitem [ref=f91e152]: 1:1 이 Decision 의 공개 주소는 프로젝트 주소 아래에 있습니다. 주제·프로젝트 화면에서 이 프로젝트를 먼저 게시해 주세요.
|
||||
- complementary [ref=f91e153]:
|
||||
- heading "작업 상태" [level=2] [ref=f91e154]
|
||||
- status "편집 상태" [ref=f91e155]: 저장되지 않음
|
||||
- generic [ref=f91e156]:
|
||||
- generic [ref=f91e157]:
|
||||
- term [ref=f91e158]: 저장 버전
|
||||
- definition [ref=f91e159]: "1"
|
||||
- generic [ref=f91e160]:
|
||||
- term [ref=f91e161]: 종류
|
||||
- definition [ref=f91e162]: Decision
|
||||
- alert [ref=f91e163]: 요청 형식이 올바르지 않습니다
|
||||
- generic [ref=f91e164]:
|
||||
- button "저장" [ref=f91e165]
|
||||
- button "게시" [ref=f91e166]
|
||||
- paragraph [ref=f91e167]: 요청 형식이 올바르지 않습니다
|
||||
Reference in New Issue
Block a user