[7팀 이현지] Chapter 3-3 기능 중심 아키텍처와 프로젝트 폴더 구조

[Leehyunji0715]

과제 체크포인트

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기

• 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
• Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
• FSD(Feature-Sliced Design)에 대한 이해
• FSD를 통한 관심사의 분리에 대한 이해
• 단일책임과 역할이란 무엇인가?
• 관심사를 하나만 가지고 있는가?
• 어디에 무엇을 넣어야 하는가?

체크포인트

• 전역상태관리를 사용해서 상태를 분리하고 관리했나요?
• Props Drilling을 최소화했나요?
• shared 공통 컴포넌트를 분리했나요?
  • HighlightText, LoadingSpinner ...
• shared 공통 로직을 분리했나요?
• entities를 중심으로 type을 정의하고 model을 분리했나요?
• entities를 중심으로 ui를 분리했나요?
• entities를 중심으로 api를 분리했나요?
• feature를 중심으로 사용자행동(이벤트 처리)를 분리했나요?
• feature를 중심으로 ui를 분리했나요?
• feature를 중심으로 api를 분리했나요?
• widget을 중심으로 데이터를 재사용가능한 형태로 분리했나요?

심화과제

목표: 서버상태관리 도구인 TanstackQuery를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기

• TanstackQuery의 사용법에 대한 이해
• TanstackQuery를 이용한 비동기 코드 작성에 대한 이해
• 비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해

체크포인트

• 모든 API 호출이 TanStack Query의 useQuery와 useMutation으로 대체되었는가?
• 쿼리 키가 적절히 설정되었는가?
• fetch와 useState가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
• 캐싱과 리프레시 전략이 올바르게 구현되었는가?
• 낙관적인 업데이트가 적용되었는가?
• 에러 핸들링이 적절히 구현되었는가?
• 서버 상태와 클라이언트 상태가 명확히 분리되었는가?
  • usePosts(Client): Post Update/Detail 등 모달 여닫거나 선택된 Post 상태 관리
  • Posts (Server): CRUD API 호출하는 것
• 코드가 간결하고 유지보수가 용이한 구조로 작성되었는가?
• TanStack Query의 Devtools가 정상적으로 작동하는가?

최종과제

• 폴더구조와 나의 멘탈모데일이 일치하나요?
  • 넵!
• 다른 사람이 봐도 이해하기 쉬운 구조인가요?
  • 제가 볼땐 괜찮아 보이는데..!!

과제 셀프회고

이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.

• FSD의 계층: 비즈니스로직계층이 있다는 것을 새로 알았어요! 그 미묘한 차이가 있다는 것을 이번 주제를 통해 알게되었습니다. 지금까지는 그냥 명확한 기준없이 마구잡이로 리팩토링하고 분리했는데, 이제는 기준을 잡고 분리할 수 있게된 것 같습니다!
• FSD의 원칙: 상위계층은 하위계층을 참조할 수 있지만, 하위계층은 상위계층을 참조할 수 없다.
• useLocation, useNavigation이 있는 이유! => URLSearchParams로 직접 쿼리를 변경하면, 리액트가 변경사항 인지를 못한다. react-router-dom 에서 제공하는 해당 hook을 사용해줘야, 해당 훅을 사용하는 컴포넌트에서 변경사항을 인지하고 리렌더링을 하게 된다.

본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?

• entities/features/widgets의 경계를 명확히 하는 것.
  • entities:
    • api: CRUD
    • ui: 단순 props로 entity 관련 데이터를 받아 화면에 보여주는 작은 단위
  • features:
    • api: CRUD 외에 어플리케이션에만 존재하는 비즈니스로직을 다루는 api
    • ui: props로 데이터를 전달받고, 무언가 1가지 비즈니스 동작/표현을 하는 컴포넌트
  • widgets:
    • api: 없음 (entities/features 에만 선언)
    • ui: Tanstack query로 값을 불러와서 entities와 features에 뿌려주는 용도. Entities UI 혹은 Features UI 컴포넌트의 조합.
• 리액트 컴포넌트는 테스트 하기 좋은정도로 쪼개자!

아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.

• UI 컴포넌트가 어느 계층까지 Props로 데이터를 받아 표현해야 하는가? 고민했습니다. 우선 저는 entities/features 계층은 데이터를 상위에서 props 값을 전달받아 보여주고, widgets/pages 같은 상위계층에서 Tanstack Query 를 호출해 값을 가져와 아래 계층에 props로 뿌려주는게 맞지 않을까? 생각했습니다.
  • 저희 항해 7팀에서 공유된 이야기인데, 회사 코드 UI 컴포넌트 내부에서 Tanstack Query를 호출해서 값을 불러오는데, 스토리북에서 항상 MSW로 해당 부분을 채워줘야해서 힘들었다!라는 의견이 있었습니다. 이러한 상황을 고려해서, 나중을 위해 비교적 낮은 계층인 entities/features 는 직접 값을 호출하는 것은 부적절하다고 생각했습니다!! (맞는 생각인지는 모르겠어요!!!)

이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.

개인적으로 DDD를 선호한다!! 연관있는 코드끼리 묶는다는게 나에게는 개인적으로 더 매력적으로 다가왔다.
FSD를 회사 프로젝트에서 써봤는데, 각 레이어 폴더에 도메인 별로 구분되어 보이는데, 어디엔 있고, 어디엔 없고... 이러한 구조가 개인적으로 꽤나 피곤하다고 생각했다. 그러나 도메인 기준으로 하면, 한눈에 어떤 도메인들이 있는지, 그리고 해당 도메일 폴더 안에 관련한 코드가 모두 모여있기 때문에 한눈에 더 파악하기 쉽다고 생각했다.

그렇다면, DDD와 FSD를 합치면 더 좋지 않을까? 라고 생각했다.
연관된 코드를 묶는 DDD, 그리고 FSD의 강점인 Layer 흐름을 강제한다는 점이 어떤 규모의 프로젝트에서도 잘 먹히지 않을까? 생각했다.

=> Gemini에게 물어보니, 위 방식은 하이브리드 방식이며, 많은 엔터프라이즈에서 채택하는 방식이라고 한다. (진짠가?)

=> 하지만 추후 공부를 하면서 DDD + FSD 구조를 바로 도입하기보다는 어느정도 어플리케이션이 자리 잡혔을때 점차적으로 도입 하는게 좋겠구나 싶었다. 실무 관점에서 맨 처음에는 비즈니스 도메인도, 그 어떤 것도 확실하게 정해진게 아니기 때문이다.

=> 그래서 (테오의 발제자료처럼) 일단 기능 기반으로 하고 그 다음에 점차 분리 및 적용하는게 좋을 듯 하다!

챕터 셀프회고

클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기

• 일단 SRP 원칙이 잘 지켜지는 코드! 하나의 컴포넌트가 여러 개의 일을 하지 않게 해야한다 생각해요.
• 각 파일의 코드양이 짧을수록 유지보수하기 쉬운것 같아요.
• 위에서부터 글을 읽듯 흐름을 파악할 수 있게 하는게 좋은 코드같아요. 변수명도 마치 글을 읽듯 적절히 의미부여를 해야하는 것 같이!

결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리

응집도 높이기: 서버상태관리, 폴더 구조

• Tanstack Query로 컴포넌트 내부에서 데이터를 직접 가져오니까, props들을 지워나가는 해방감! 이 있었어요!ㅎㅎ 코드가 깔끔해지고, 각각 컴포넌트가 독립적으로 되니까 좋았습니다!!

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문