Coopang 프로젝트: 멀티 모듈 구조와 역할 정리

Coopang 프로젝트: 멀티 모듈 구조와 역할 정리

프로젝트 개요

Coopang 프로젝트는 각 기능별로 모듈을 분리하여 유지보수성과 확장성을 극대화한 멀티 모듈 구조를 채택했습니다.
각 모듈은 독립적인 기능을 제공하면서도, 다른 모듈과 상호작용하여 전체 애플리케이션을 유기적으로 구성합니다.

 

---

 

프로젝트 구조

coopang
├── BOOT (Server)
│   ├── gateway
│   ├── user
│   ├── hub
│   ├── product
│   ├── order
│   ├── delivery
│   └── ainoti
├── CLOUD (System)
│   └── eureka
├── DATA
│   ├── api-data
│   └── core-data
├── INFRA (Integration)
│   ├── auth-common
│   ├── api-config
│   └── api-communication
├── MONITOR
│   ├── loki
│   └── prometheus
├── docker-compose.yml
├── init.sql
└── settings.gradle

 

---

 

1. 구성 및 역할

 

1.1. Root 프로젝트

• coopang 프로젝트는 여러 하위 모듈을 포함하는 Root 프로젝트로 구성됩니다.
• Root 프로젝트는 공통된 빌드 설정을 관리하며, 하위 모듈 간의 종속성을 정의합니다.
• build.gradle 파일에서 하위 모듈을 정의하고 공통으로 사용하는 라이브러리와 플러그인을 설정합니다.

역할:

• 공통된 빌드 설정 관리.
• 하위 모듈 간 종속성 정의.
• 공통으로 사용하는 라이브러리와 플러그인 설정.

주요 파일:

• docker-compose.yml: 모든 마이크로서비스와 인프라 서비스를 컨테이너로 실행하는 설정 파일.
• init.sql: 초기 데이터베이스 스키마 및 데이터 초기화 스크립트.
• settings.gradle: 하위 모듈을 정의하고 루트 프로젝트에 포함시키는 설정 파일입니다. 여기에서 각 모듈 간의 종속성을 설정.

 

rootProject.name = 'coopang'

// CLOUD (System)
include 'CLOUD:eureka'

// DATA (Domain)
include 'DATA:api-data'
include 'DATA:core-data'

// INFRA (Integration)
include 'INFRA:api-config'
include 'INFRA:api-communication'
include 'INFRA:auth-common'

// BOOT (Server)
include 'BOOT:gateway', 'BOOT:user', 'BOOT:hub'
include 'BOOT:product'
include 'BOOT:order', 'BOOT:delivery'
include 'BOOT:ainoti'

 

---

 

 

1.2. BOOT (Server)

 

BOOT 모듈은 비즈니스 로직을 처리하며, 각 모듈이 독립적으로 실행됩니다.

• BOOT 모듈은 잦은 변화가 발생하는 핵심 비즈니스 로직을 처리하는 모듈들로 구성되어 있습니다.
• 각 모듈은 독립적으로 실행되며, API 요청을 받아 비즈니스 로직을 처리합니다.

구성

• gateway: 클라이언트로부터의 모든 요청을 처리하고, 적절한 마이크로서비스로 요청을 라우팅합니다. 인증 및 권한 제어 역할을 수행합니다.
• user: 사용자 관리와 인증, 권한 부여 등을 담당합니다.
• hub: 허브, 회사, 배송기사 관련 관리 기능을 처리하는 모듈입니다.
• product: 상품, 상품재고, 재고기록 기능을 처리하는 모듈입니다.
• order: 주문, 결제기록, PG 기능을 처리하는 모듈입니다.
• delivery: 배송, 허브배송기록, 고객배송기록 기능을 처리하는 모듈입니다.
• ainoti: AI 요청과 AI 응답을 기록하고, slack알림 서비스와 관련된 기능을 담당하는 모듈입니다.
• 각 BOOT 모듈은 비즈니스 요구사항에 따라 자주 변경되며, 이를 통해 프로젝트의 유연성을 유지합니다.

 

 

---

1.3. DATA (Domain)

 

DATA 모듈은 공통 데이터 모델과 응답 DTO를 관리합니다.

모든 BOOT 모듈에서 재사용 가능한 공통 엔티티와 데이터 클래스를 제공하여 일관성을 유지합니다.

 

 

api-data와 core-data 분리의 이유

• 처음에는 **api-data**만 사용했지만, gateway가 api-data 전체를 참조하는 경우 불필요한 코드 의존성이 발생.
• gateway와 auth/user 서버에서만 사용하는 **core-data**를 추가로 분리.

 

• core-data에는 UserRoleEnum, HeaderConstants 로 구성됩니다.
• gateway는 여러 서비스(Gateway, User, Product, Order 등)의 요청을 중계하거나 인증/인가를 수행하는 역할을 합니다.
• api-data는 외부 API와의 데이터 요청/응답을 처리하는 DTO나 데이터 구조를 포함하지만, gateway는 해당 데이터 구조의 일부만 필요합니다.
• gateway는 외부 API 통신 로직보다는 인증/인가를 위한 역할 확인이 더 중요합니다.
• 따라서, 역할 검증과 관련된 로직만 사용하는 것이 gateway의 책임과 역할에 적합합니다.

 

api-data와 core-data 분리 효과

 

단일 책임 원칙(SRP)과 모듈화 설계 원칙 준수

 

• gateway는 인증/인가와 역할 확인에만 집중하며, 불필요한 데이터 처리 로직을 배제했습니다.
• core-data와 api-data의 명확한 분리를 통해 코드의 유지보수성과 확장성을 극대화했습니다.

 

의존성 최소화:

• gateway는 api-data 전체를 참조하지 않고, 인증/인가에 필요한 최소한의 데이터를 사용하여 모듈 간 의존성을 줄입니다.

책임 분리:

• gateway: 인증/인가와 역할 확인을 책임짐.
• api-data: 외부 API 요청/응답 데이터 처리.
• core-data: 비즈니스 로직의 핵심 데이터 구조 제공.
  각 모듈이 명확한 역할을 가지므로 코드가 깔끔하고 유지보수가 쉬워집니다.

재사용성 강화:

• UserRoleEnum과 같은 핵심 데이터 구조는 다른 모듈에서도 재사용할 수 있습니다.
• 역할 검증 함수는 여러 서비스에서 일관되게 사용할 수 있어 중복 코드를 방지합니다.

---

 

api-data 구조

• application/response DTO: 서버 간 또는 클라이언트와 통신할 때 사용하는 공통 응답 DTO입니다. BOOT 모듈에서 주로 사용됩니다.
• constants: 시스템 전반에서 공통으로 사용되는 상수를 정의합니다.
• 공통 JPA 엔티티: 여러 모듈에서 공통으로 사용하는 엔티티를 관리합니다. 예를 들어, AddressEntity, LocationEntity, BaseEntity 등이 포함됩니다.
• 이 모듈을 통해 중복 코드 작성을 방지하고, 일관된 데이터 구조를 유지할 수 있습니다.

 

---

1.4. INFRA (Integration)

• INFRA 모듈은 인프라스트럭처와 통합 관련 설정 및 기능을 제공하는 모듈입니다.
• 주로 공통 설정을 각 서비스에 적용하거나, 외부 시스템과의 연동을 담당합니다.

 

주요 모듈:

auth-common: 인증 및 권한 관련 공통 로직.

gateway와 auth 서버에서 공통으로 사용하는 jwt class가 포함됩니다.

 

api-config: 시스템 전반에서 사용하는 API 설정.

BOOT 모듈에 공통적으로 적용되는 설정을 관리합니다. 주요 기능으로는 캐시 관리(Caffeine), 예외 처리, 객체 매핑(ModelMapper), 보안(Security), Swagger 설정 등이 포함됩니다.

 

api-communication: 외부 API와의 통신 로직 처리.

외부 시스템 또는 다른 마이크로서비스와의 통신을 처리하는 모듈입니다. Redis, FeignClient, Kafka와 같은 선택적 통신 방식이 구현되어 있습니다.

 

---

1.5. CLOUD (System)

• CLOUD 모듈은 시스템 전체의 관리 및 마이크로서비스 간의 통신을 담당하는 시스템 모듈입니다.
• 마이크로서비스들이 독립적으로 동작할 수 있도록 지원하며, 유레카 서버를 통해 서비스 디스커버리 및 등록을 처리합니다.

주요 구성 요소

• eureka: Spring Cloud Netflix Eureka를 사용하여 각 서비스의 등록과 디스커버리를 담당하는 모듈입니다.
• 모든 마이크로서비스는 eureka를 통해 서로의 위치를 인식하고 통신할 수 있습니다.
• 이 모듈은 컨테이너 환경에서 각 서비스의 트래픽을 관리하며, 변화가 적습니다.

---

1.6. MONITOR

• MONITOR 모듈은 시스템 모니터링과 로그 관리를 위한 모듈입니다.
• 각 마이크로서비스의 상태를 모니터링하고, 실시간 로그 분석 및 알림을 제공합니다.

주요 구성 요소

• Loki: 로그 수집 및 분석을 위한 시스템입니다. 각 서비스에서 발생하는 로그 데이터를 Loki로 수집하여 분석할 수 있습니다.
• Prometheus: 시스템의 상태와 성능을 모니터링하기 위한 메트릭 수집 및 분석 도구입니다. 각 서비스의 트래픽, 응답 시간, CPU 사용량 등을 모니터링할 수 있습니다.

 

---

 

2. 모듈 간의 의존성

 

• coopang 프로젝트에서는 모듈 간의 의존성이 명확하게 정의되어 있습니다.
• 각 모듈은 필요에 따라 다른 모듈에 의존성을 추가하며, 프로젝트 전체가 유기적으로 동작하도록 구성되어 있습니다.

INFRA:api-config 모듈

 

• INFRA:api-config 는 최상단 모듈 입니다.
• 설정에 필요한 파일들이 있습니다
• utill-libray 기능과 유사합니다

 

DATA:api-data 모듈

 

• DATA:api-data 는 BOOT/하위 앱에서 사용되는 공통 DTO를 담고 있습니다.
• INFRA:api-config에 의존합니다

    // multi module
    implementation project(':INFRA:api-config')

 

 

INFRA:api-communication 모듈

 

• INFRA:api-communication 는 BOOT/하위 앱에서 서로 통신할때 사용되는 모듈
• feignClient, Kafka 설정과 공통 파일이 있습니다
• INFRA:api-config, DATA:api-data에 의존합니다

	// multi module
	implementation project(':INFRA:api-config')
	implementation project(':DATA:api-data')

 

 

BOOT:user 모듈

 

• INFRA:api-config, DATA:api-data에 의존합니다

    // multi module
    implementation project(':DATA:api-data')
    implementation project(':INFRA:api-config')

 

BOOT:hub 모듈

    // multi module
    implementation project(':DATA:api-data')
    implementation project(':INFRA:api-config')
    implementation project(':INFRA:api-communication')

 

• INFRA:api-config, DATA:api-data, INFRA:api-communication에 의존합니다