엔터프라이즈 프론트엔드 애플리케이션 아키텍쳐

- 코드베이스가 커진다는 것 = 이해하기도, 수정하기도 어려워진다는 것
- 해결 방법은? 코드베이스를 작게 유지하면 됨.
- 도메인 별 코드베이스 분리 & 마이크로 프론트엔드 to rescue!
- 모노레포 안에서 라이브러리의 의존 관계 설정 & 의존성 확인 등의 니즈는 [Nx](https://nx.dev/)를 도입하여 해결
- 애플리케이션과 라이브러리로 코드를 분리
- 애플리케이션은 의존성 및 설정 주입의 역할
- 라이브러리에 대부분의 기능을 구현
- 라이브러리에는 범용적으로 사용할 수 있는 디자인 시스템, 국제화, 서드파티 모듈 뿐만 아니라 홈 페이지의 히어로 배너, 상품 상세 페이지, 주문 내역 등 재사용하지 않는 코드까지 작성.

### Feature 라이브러리

- 기본적으로 한 페이지에서 사용되는 모든 컴포넌트들은 같은 이름의 Feature 라이브러리에 작성
- ex) `account` 도메인의 `SignInPage` 페이지의 모든 컴포넌트들은 `account/feature-sign-in` 라이브러리에 작성
- 같은 도메인의 둘 이상의 페이지에서 공유하는 컴포넌트는 해당 도메인 내 별도의 feature로 분리
- ex) `account` 도메인의 `SignInPage`와 `SignUpPage`에서 `KakaoLoginButton` 컴포넌트를 공통으로 사용한다면 해당 컴포넌트는 `account/feature-social-login` 라이브러리에 작성
- 서로 다른 도메인의 페이지들에서 공유하는 컴포넌트는 공용 도메인 내 별도의 feature로 분리
- ex) `landing` 도메인의 `HomePage`와 `classroom` 도메인의 `LecturePage`에서 공유하는 `GlobalNavigation` 컴포넌트는 `shared/feature-navigation` 라이브러리에 작성

### Shell 라이브러리

- Feature, UI 라이브러리의 컴포넌트들을 조합해 페이지들을 만듦
- ex) `SignInPage` 컴포넌트는 account/shell-kr-web 라이브러리의 컴포넌트. 여기에는 `SignUpPage`, `PhoneVerificationPage` 등이 있음.
- Shell 라이브러리는 애플리케이션에 제공되는 특정 도메인의 진입점
- 애플리케이션 별로 다른 진입점을 제공할 수 있음
- 예를 들어..
- `HomePage` 컴포넌트에서 사용하는 컴포넌트들은 `landing/feature-home` 라이브러리에 작성되어 있음.
- 하지만 같은 `HomePage`라도 미국 사이트의 `HomePage`인지, 일본 사이트의 `HomePage`인지, 한국 사이트의 `HomePage`인지에 따라 그 구성이 다를 것.
- 따라서 `landing` 도메인에 접근하는 각각의 애플리케이션을 위한 `shell` 라이브러리를 만들 수 있음. (`shell-us-web`, `shell-jp-web`, `shell-kr-web`)

### Provider 라이브러리

- 둘 이상의 Feature 라이브러리에서 공유하는 상태를 관리하는 라이브러리
- ex) 로그인 상태를 관리하는 `shared/provider-auth-state`

### UI 라이브러리

- 둘 이상의 라이브러리에서 공유하는 Presentational 컴포넌트의 모음.

### Utility 라이브러리

- 위 4가지 분류에 해당하지 않는 모든 모듈들
- 클래스101의 도메인 모델과 무관하게 테스트 및 배포가 가능한 수준으로 독립적인 기능을 제공해야 함.
- ex) `shared/utils-apollo-client`, `shared/utils-i18n`

### 애플리케이션

- 설정 및 의존성 관리의 역할만 담당하게 됨 = 애플리케이션의 코드는 거의 없음