/
Feature 기반 분리 시 주요 원칙

Feature 기반 분리 시 주요 원칙

Owned by Hannah
Jan 14, 2025
2 min read

  1. Feature 단위로 독립성 유지

    • 각 Feature는 자신의 도메인 모델, 애플리케이션 로직, 데이터 저장소를 독립적으로 관리.

    • 다른 Feature와의 통신은 API나 메시지 큐를 통해 수행.

  2. 공통 기능 최소화

    • 각 Feature에서 중복을 줄이기 위해 공통 모듈(common 또는 shared)을 생성할 수 있지만, 남용하지 않도록 주의.

    • 예: 공통 유틸리티, 인증/인가 모듈.

  3. 도메인 중심 설계

    • 각 Feature는 자신의 도메인과 유스케이스에 맞는 설계를 유지.

    • 다른 Feature에 의존하지 않도록 설계.

Feature 기반 구조 예시

src ├── feature-a │ ├── adapter │ │ ├── api │ │ ├── persistence │ │ └── messaging │ ├── application │ │ ├── service │ │ └── usecase │ ├── domain │ │ ├── entity │ │ ├── valueobject │ │ └── service │ ├── dto │ ├── port │ │ ├── inbound │ │ └── outbound │ ├── configuration │ ├── event │ ├── exception │ ├── mapper │ ├── utils │ └── test ├── feature-b │ ├── adapter │ ├── application │ ├── domain │ ├── dto │ ├── port │ ├── configuration │ └── test ├── common (공통 모듈) │ ├── security │ ├── messaging │ ├── exception │ ├── utils │ └── test └── shared (공유 리소스) ├── api-clients ├── shared-entity ├── shared-dto └── event

 

구체적인 분리 전략

  1. Feature 간 통신

    • 동기 통신: REST API 또는 gRPC를 사용.

    • 비동기 통신: Kafka, RabbitMQ와 같은 메시지 브로커를 사용.

  2. Feature 내부 구조

    • 각 Feature는 완전한 헥사고날 아키텍처를 유지.

    • adapter, application, domain, port로 구성하여 독립성을 보장.

  3. 공통 코드 관리

    • 공통 코드는 common 디렉터리에서 관리.

    • 각 Feature가 필요에 따라 가져다 사용.

  4. 테스트 분리

    • 단위 테스트는 Feature 내에서 진행.

    • 통합 테스트는 Feature 간의 상호작용을 확인.

  5. 데이터베이스 분리

    • 가능한 경우 각 Feature가 별도의 데이터베이스를 관리(MSA의 원칙).

    • 동일한 데이터베이스를 사용해야 한다면, 데이터 접근은 Repository를 통해 제한.

MSA 최적화를 위한 추가 팁

  1. API Gateway

    • 외부 요청은 API Gateway를 통해 라우팅.

    • 각 Feature는 내부적으로 독립적으로 동작.

  2. Feature별 배포

    • 각 Feature는 독립적으로 빌드 및 배포 가능하도록 설계.

    • Docker, Kubernetes를 활용.

  3. 모니터링과 로깅

    • 각 Feature의 상태를 중앙에서 모니터링.

    • 로그는 통합된 시스템(예: ELK 스택)에서 관리.