조직의 구성이 직무 중심에서 비즈니스 중심으로 변화하면서 서비스 운영과 관리적인 측면에서 프론트엔드 아키텍처를 어떻게 발전시켜 나갈 것인가를 고민하는 단계가 되었다. 누구나 프로젝트의 구조를 쉽게 이해할 수 있고, 각자의 담당 분야에 집중할 수 있는 구조를 만들고 싶었고 이를 위해 백엔드 아키텍처에서 차용하고 있는 도메인 주도 설계(Domain Driven Design) 설계 방법 중 일부를 프론트엔드 아키텍처에 접목해보기로 했다.

DDD란?

<aside> 🔖 복잡한 소프트웨어는 기술 자체의 복잡성 보다는 도메인 자체의 복잡성에 기인한다.

</aside>

• DDD 개념 살펴보기

프론트엔드에 적용해본 DDD

<aside> 🔖 킵그로우 어드민의 경우 이미 코드의 고도화가 많이 진행된 상황으로 각 aggregate 간의 복잡한 관계를 가짐 따라서 서브 도메인인 CMS 프로젝트를 SPA로 컨버팅하는 과정에서 프로젝트 구조를 DDD로 분리해보고 이를 통해 관리적 효율성이 증대되는지를 확인해보고자 한다.

</aside>

As-is & To-be

기존 CMS 구조는 아래와 같은 구조를 가졌다.

이제 CMS는 아래와 같은 구조로 변경된다.

테스트한 도메인에 대하여

CMS에서는 모듈 안의 Application에서 실제 동작을 위한 data-fetching 액션에 swr과 react-query를 모두 사용한다. (테스트베드의 잔재들) 따라서 swr과 react-query를 사용하는 영업권 관리(BusinessAuthority)와 상품 카테고리 관리(ProductCategory)를 모두 DDD 구조로 변경해보기로 했다.

• 상품 카테고리 관리(ProductCategory)
• 영업권 관리(BusinessAuthority)

.
├── components
│   ├── Header.tsx
│   ├── Spinner.tsx
│   └── index.tsx
├── process
│   ├── application
│   ├── infra
│   ├── model
│   └── ui
├── product
│   ├── application
│   ├── infra
│   ├── model
│   └── ui
├── utils
│   ├── api.ts
│   ├── auth.ts
│   ├── fetcher.ts
│   ├── hooks.ts
│   └── utils.ts
├── Root.tsx
├── client.tsx
├── tsconfig-for-webpack-config.json
├── tsconfig.json
├── front-scripts.ejs
├── package-lock.json
├── package.json
└── webpack.config.ts

• components
  • 여러 Aggregate에 사용할 수 있는 추상화된 UI 컴포넌트 모음
  • Header, Spinner 등
• process
  • 영업권 관리(BusinessAuthority) 모듈(영업권은 카카오싱크 매니지먼트의 서브 도메인 개념)
  • 하위로 ui, application, model(domain), infra가 구성
• product
  • 상품 카테고리 관리(ProductCategory) 모듈(카테고리는 상품 매니지먼트의 서브 도메인 개념)
  • 하위로 ui, application, model(domain), infra가 구성
• utils
  • 여러 Aggregate에서 사용할 수 있는 추상화된 유틸함수 모음
  • api, fetcher, utils 등