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

> Clean Markdown view of GeekNews topic #4572. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=4572](https://news.hada.io/topic?id=4572)
- GeekNews Markdown: [https://news.hada.io/topic/4572.md](https://news.hada.io/topic/4572.md)
- Type: news
- Author: [hjinu](https://news.hada.io/@hjinu)
- Published: 2021-07-08T00:06:05+09:00
- Updated: 2021-07-08T00:06:05+09:00
- Original source: [medium.com](https://medium.com/class101/엔터프라이즈-프론트엔드-애플리케이션-아키텍쳐-79eef2e30c77)
- Points: 23
- Comments: 0

## Topic Body

- 코드베이스가 커진다는 것 = 이해하기도, 수정하기도 어려워진다는 것

- 해결 방법은? 코드베이스를 작게 유지하면 됨.

- 도메인 별 코드베이스 분리 & 마이크로 프론트엔드 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`

### 애플리케이션

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

## Comments



_No public comments on this page._