본문으로 건너뛰기

도메인 의존성 및 구현 순서

1. 도메인 구조​

현재 DTA-WIDE 시스템은 다음과 같은 핵심 도메인들로 구성되어 있습니다:

  • Auth (인증): 사용자 인증 및 토큰 관리
  • IAM (Identity and Access Management): 권한 및 접근 제어 관리
  • User (사용자): 사용자 프로필 및 계정 관리
  • Audit (감사): 시스템 활동 로깅 및 감사

각 도메인은 비즈니스 정의를 담은 상세 문서와 기술적인 구현 가이드로 구분되어 있습니다. 상세 문서는 도메인의 핵심 개념과 규칙을 정의하고, 구현 가이드는 실제 개발에 필요한 기술적인 내용을 다룹니다.

2. 도메인 구현 위치​

모든 도메인은 다음과 같은 구조를 따라 구현되어야 합니다:

2.1 구현 디렉토리 구조​

도메인의 핵심 비즈니스 로직은 libs/ 디렉토리 아래에 구현해야 합니다. 이는 도메인 로직을 애플리케이션 계층과 분리하여 재사용성과 테스트 용이성을 높이기 위함입니다.

libs/
  feature/
    [domain-name]/
      src/
        lib/
          domain/
            entities/
            value-objects/
            events/
            aggregates/
          application/
            commands/
            queries/
            dto/
            interfaces/
          infrastructure/
            repositories/
            services/
          [domain-name].module.ts
        index.ts

2.2 계층 분리​

도메인 구현은 다음과 같이 계층을 분리하여 구현해야 합니다:

  1. 도메인 계층: 엔티티, 값 객체, 도메인 이벤트, 집계 등 핵심 비즈니스 로직
  2. 애플리케이션 계층: 명령, 쿼리, 유스케이스, DTO 등
  3. 인프라 계층: 리포지토리, 외부 서비스 통합 등

2.3 API 엔드포인트​

도메인의 API 엔드포인트(컨트롤러)는 apps/dta-wide-api 프로젝트 내에 구현해야 합니다. 이는 도메인의 핵심 로직과 UI/API 계층을 분리하기 위함입니다.

apps/
  dta-wide-api/
    src/
      app/
        [domain-name]/
          controllers/
          [domain-name].module.ts

컨트롤러는 libs에 구현된 도메인 서비스나 명령/쿼리를 호출하는 역할만 담당하며, 비즈니스 로직을 직접 구현해서는 안 됩니다.

2.4 구현 규칙​

  1. 비즈니스 로직 위치: 모든 비즈니스 로직(service, repository, domain 객체 등)은 반드시 libs/feature/[domain-name] 아래에 구현해야 합니다.
  2. API 엔드포인트 위치: 모든 컨트롤러는 apps/dta-wide-api 프로젝트에 구현해야 합니다.
  3. 의존성 방향: API 계층(apps)은 도메인 계층(libs)에 의존할 수 있지만, 도메인 계층은 API 계층에 의존해서는 안 됩니다.
  4. 모듈 가져오기: API 모듈은 libs의 도메인 모듈을 가져와서 사용해야 합니다.
// apps/dta-wide-api/src/app/user/user.module.ts
@Module({
  imports: [
    UserDomainModule, // libs/feature/user에서 가져온 모듈
  ],
  controllers: [UserController],
})
export class UserApiModule {}

3. 도메인 의존성​

의존성 설명​

  1. Auth → User

    • 사용자 인증을 위해 사용자 정보 필요
    • 토큰 발급 시 사용자 식별자 필요

  2. IAM → User

    • 권한 할당을 위한 사용자 정보 필요
    • 역할 기반 접근 제어(RBAC)를 위한 사용자 그룹 정보 필요

  3. IAM → Auth

    • 권한 검증 시 인증 토큰 검증 필요
    • 권한 변경 시 관련 세션 관리 필요

  4. Audit → User, Auth, IAM

    • 모든 시스템 활동에 대한 사용자 식별 필요
    • 인증 및 권한 변경 이벤트 추적
    • 보안 관련 활동 로깅

4. 구현 순서​

도메인 의존성을 고려한 최적의 구현 순서는 다음과 같습니다:

  1. User 도메인

    • 기본 사용자 관리 기능
    • 프로필 관리
    • 계정 상태 관리

  2. Auth 도메인

    • 기본 인증 시스템
    • 토큰 관리
    • 세션 관리

  3. IAM 도메인

    • 역할 정의
    • 권한 관리
    • 접근 제어 정책

  4. Audit 도메인

    • 활동 로깅
    • 감사 추적
    • 보안 모니터링

5. 구현 시 고려사항​

5.1 User 도메인​

  • 확장 가능한 사용자 스키마 설계
  • 프로필 데이터 유효성 검증
  • 계정 상태 관리 로직

5.2 Auth 도메인​

  • JWT 기반 토큰 관리
  • 보안 정책 준수

5.3 IAM 도메인​

  • RBAC 구현
  • 권한 상속 관계 설계
  • 동적 정책 관리

5.4 Audit 도메인​

  • 구조화된 로그 포맷
  • 실시간 모니터링
  • 컴플라이언스 요구사항 충족

6. 도메인 간 통신​

6.1 초기 구현 (모놀리식)​

현재 시스템은 모놀리식 아키텍처로 구현될 예정이므로, 도메인 간 통신은 내부 메서드 호출을 통해 이루어집니다. 다만, 향후 마이크로서비스로의 전환 가능성을 고려하여 다음 사항들을 준수합니다:

  • 도메인 간 결합도를 최소화
  • 명확한 도메인 경계 설정
  • 도메인 이벤트 기반의 상호작용 패턴 적용

6.2 비동기 통신​

  • GCP Pub/Sub를 통한 이벤트 기반 통신
  • 도메인 이벤트 발행/구독

참고: REST API, gRPC 등을 통한 도메인 간 통신은 마이크로서비스 전환 시점에 구체화할 예정입니다.

7. 확장 계획​

향후 다음과 같은 도메인 확장이 계획되어 있습니다:

  • Notification: 알림 관리
  • Analytics: 사용자 행동 분석
  • Compliance: 규정 준수 관리

각 확장 도메인은 기존 도메인들과의 의존성을 최소화하여 설계될 예정입니다.

8. 변경 이력​

버전날짜작성자변경 내용
0.1.02025-03-25bok@weltcorp.com문서 초기 작성