[7팀 김민지] Chapter 3-3 기능 중심 아키텍처와 프로젝트 폴더 구조 #37
Conversation
This file contains hidden or 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
- app, widgets 레이어 구조 생성 - Layout 컴포넌트 분리, 파일 위치 이동 - 라우팅 설정 파일 분리 - index.tsx 파일 삭제
- entities/user/model/types.ts: User 관련 타입 정의 - User, UserSummary, UsersResponse, UsersQueryParams - entities/user/api/userApi.ts: User API 함수 분리 - fetchUser: 단일 사용자 조회 - fetchUsers: 사용자 목록 조회 (select 옵션 지원) - PostsManagerPage.tsx: User API 사용하도록 수정 - fetchUsers로 사용자 목록 조회 (Post와 User 결합) - fetchUser로 사용자 상세 조회 - User 타입 적용 Post Entity와 동일한 패턴으로 User Entity를 분리하여 재사용 가능한 기본 데이터 접근 계층 확장
- shared/ui: 공통 UI 컴포넌트를 feature별로 분리 (button, card, dialog, input, select, table) - features/post: 게시물 관련 기능 분리 - model: usePostManagement, usePostSearch, usePostFilter 훅 분리 - ui: AddPostDialog, EditPostDialog 컴포넌트 분리 - components/index.tsx 삭제 (shared/ui로 대체) - PostsManagerPage: 분리된 컴포넌트 및 훅 사용하도록 수정 - 타입 에러 수정 (author.image undefined 처리)
- Widgets: props 기반으로 변경 (재사용성, 테스트 용이성) - Features: 스토어 직접 사용 유지 (기능 특화) - Pages: widgets에 props 전달, features는 그대로 사용 - 무한 루프 문제 해결 (useMemo 사용)
This reverts commit e3d5a07.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
과제 체크포인트
기본과제
목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기
체크포인트
심화과제
목표: 서버상태관리 도구인 TanstackQuery를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기
체크포인트
최종과제
과제 셀프회고
이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.
이전에 팀 사이드 프로젝트를 하며 FSD와 DDD를 공부했지만, 실제로 어디에 적용해야 하는지 혼란스러웠습니다.
이번 과제를 통해 구조를 직접 만들어 보면서 FSD의 계층적 흐름과 단방향 의존성(entities → features → widgets)을 조금 더 명확하게 이해하게 되었습니다.
본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?
단일 책임 원칙을 신경쓰고 싶었어요. 그래서 하나의 파일에 여러 역할이 섞이지 않도록, 데이터 정의·상태·비즈니스 로직·UI가 각각 제 위치를 갖도록 설계했습니다. 또한 컴포넌트 내부에서 API 요청이나 상태를 혼합해 처리하지 않도록 구조적으로 분리하는 데 집중했습니다.
아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.
1. api 파일 위치
FSD 아키텍처에서 entities와 features 모두에 api 폴더가 존재할 수 있는데, 이렇게 되면 개발자가 API를 찾기 위해 두 곳을 확인해야 하는 문제가 발생합니다.
라고 이론적으로는 구분되지만, 기능 특화 API가 어떤 기준으로 분리되어야 하는지 실전에서는 모호했습니다. 오히려 API가 두 곳으로 나뉘며 “이 API는 어디에 있어야 하지?”라는 혼란을 줄 수도 있다는 생각이 들었어요.
2. tags의 도메인 분리
Tag는 독립적인 도메인처럼 보이지만, 백엔드 API는 posts/* 아래에 묶여 있습니다. 이때 프론트엔드 도메인 구조를 다음 중 무엇을 기준으로 해야 하는지가 헷갈렸습니다. 현재는 posts 하위로 넣었지만, 점점 태그가 기능적으로 독립하면 나중에 변경해야 하는 구조여서 프론트엔드 도메인을 백엔드 API 기준으로 나눠도 되는지 고민이 생겼습니다. 누군가 제 코드를 본다고 생각하면 api 를 기준으로 기능을 보고 작업할 것 같아서 둔 것이었는데, 백엔드에 의존적으로 이렇게 나누는 형태가 과연 맞을까? 하는 의문이 들었습니다.
3. 전역 상태 위치
전역 상태는 “전역”이라는 이유로 app/에 배치했습니다. 하지만 어떤 상태는 특정 도메인에 종속적이기도 해 보여, 도메인별로 분리하는 것이 맞는가? 하는 고민이 들었습니다. 전역 상태가 “범용적 UI”인지 “도메인 전용 상태”인지 판단 기준이 아직 명확하지 않습니다.
4. FSD는 이렇게 작은 규모에도 적합한 형태일까요?
현재는 파일 수가 적다 보니 폴더마다 파일이 한 개씩만 존재하는 경우도 많았습니다. 폴더 구조는 명확해졌지만, “너무 과한 구조인가?”라는 생각도 들었습니다.페이지가 한개니 까 늘어나겠지 하는 마음에 index.ts를 추가해서 작업하긴 했는데 파일 아키텍처에 대한 선택도 서비스의 규모에 따라서 진행되어야 하지 않을까 궁금했어요.
5. 기능 기반으로 해야하는데 도메인 기반으로 구분하는게 맞을까요?
폴더를 나누다 보니 자연스럽게 도메인 중심 분류가 많아졌습니다. FSD는 "features"니까 기능 중심으로 되어야 할 것 같은데 이렇게 나누는 것이 괜찮은가? 하는 의문도 들었어요. features에서 domain-features의 형태로라도 기능별 분리를 했어야 했나? 하는 생각이 들었습니다. 근데 읽다보니 더더욱 DDD랑 차이는 뭐지? 하는 마음도 들었습니다. DDD와 FSD의 철학적 차이가 실전에서는 어디서 드러나는지 아직 명확하지 않았습니다.
이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.
공부하다가 이해도가 부족해서 그냥 pages, components, hooks의 형태를 사용하는 경우가 많았는데 그래도 좀 더 공부해서 기능별로 구분할 것 같아요. 그래도 도메인 기준으로 묶는 형태는 좋지 않을까요...?
챕터 셀프회고
클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기
기분 : 나의 코드도 남의 눈에는 이렇게 보이겠죠...? 근데 고친 저 코드도 클린한가는 잘 모르겠어요. 항상 일주일 뒤에 다시 보면 너무 별로라서..
읽기 좋은 코드와 유지보수하기 좋은 코드가 비슷하지 않을까 생각합니다. 여러개의 기능을 하지 않는 것. 나중에 다른 곳에서도 쓰인다고 할 때 수정 지점이 적어야 하지 않을까 싶습니다. 근데 또 다른 곳에서 쓰일 가능성이 없는 것을 범용성을 고려하기 위해 작업하는 것이 유의미한 작업인가? 하는 생각도 들어요.
결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리
응집도 높이기: 서버상태관리, 폴더 구조
이번 과제에서는 tanstack query를 사용하지 않았지만, loading, onError 등을 처리하는 것, 서버 상태를 별도의 전역 상태가 아니라 캐시로 관리하는 것에서 상태 관리에도 역할 분리를 할 수 있어서 좋았다고 생각했어요. 그렇지만 또 한편으로는 tanstack query를 Next.js에서도 사용해도 괜찮을까? 라는 이야기를 전에 한 적이 있는데 스스로 답을 내진 못했습니다. 또 tanstack query 와 같은 기술에 의존해서 있고 없고에 따라서 처리가 다양해지는게 맞는가? 하는 의문도 있어요.
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문
쓰다보니 위에 주저리 주저리쓴게 질문이 되었슴당...