[ ARCHITECTURE ] DDD(Domain-Driven Design)의 아키텍처 정리!

패키지 계층과 참조에 관해서 궁금해질때쯤 역방향 참조의 문제와 계층에 관한 공부를 하고 정리해보려고 합니다.

우선, Domain 이란?

domain의 뜻은 "영역" 또는 "범위" 라는 뜻을 가지고 있습니다.

계층

DDD 아키텍쳐는 크게 presentation, infrastructor, domain, application 네가지의 계층으로 구분되어있습니다.

Presentation Layer

• 사용자와 가장 근접한 곳으로 웹 요청과 응답 처리 같은 로직 구현을 처리하는 계층입니다.
• controller 와 요청,응답 dto 를 사용합니다.

Application Layer

• 유스케이스 또는 비즈니스 흐름을 관리하는 곳으로

  도메인 계층과 인프라스트럭쳐 계층을 연결해주는 역할을 하는 계층입니다.

• service 를 사용합니다.

Domain Layer

• 애플리케이션의 핵심 비즈니스 로직으로 비즈니스 규칙, 정보에 대한 실질적인 도메인 정보를 가지고 있으며, 이를 책임지는 계층입니다.
• Entity와 Value Object를 사용하며, 도메인 규칙은 Domain Service에서 구현됩니다.

Infrastructure Layer

• DB 와 가장 근접한 곳으로 외부와의 통신(DB, 메시징 시스템 등)을 담당하는 계층입니다.
• repository 와 config 를 사용합니다.

인터셉터에 대한 계층

역할과 성격에 따라 인터셉터와 기본 설정에 대한 위치가 달라질 수 있습니다.

spring security

예를 들어 spring securoty 에 설정에 대해서 설명을 해보자면
spring security의 역할은 인증, 인가, 기술적인 로직 등이 있는데
크게 presentation 과 infrastructure 에 걸쳐 배치됩니다.

Infrastructure Layer

spring security 의 기술적 설정과 구현은 infra 에 속합니다.

• Security Config, DataBase Config
  securityFilterChain, WebSecurityConfigurerAdapter 등 기술적인 세부사항들.
• 인증 공급자
  • 사용자 인증 데이터의 조회( 예: UserDetailsService)
  • 인증 프로세스 처리( 예 : AuthenticationProvider)
  • 암호화 유틸리티( 예: PasswordEncode) 등 기술적 도구로써 비즈니스로직과 구분 지어줍니다.
• JWT
  jwtUtil 의 역할은 토큰 생성, 검사, 파싱 같은 역할을 하는 클래스이므로 기술적인 세부사항입니다.

Presentation Layer

• Spring Security의 Filter나 Interceptor는 HTTP 요청과 응답을 가로채고 처리하는 작업을 담당하므로 Presentation Layer에 속합니다.
  • 하지만 Spring Security의 Filter는 기술적으로 Infrastructure Layer의 일부로 간주될 수도 있습니다.
  • 예 ) JwtAuthenticationFilter는 Presentation Layer와 Infrastructure Layer 사이에서 작동하는 경계 요소입니다.
• Web Config
  web config 의 간단한 역할들은 인터셉터 등록, 요청 처리기 매핑, HTTP 요청과 응답의 공통 작업 설정 등이 있습니다.

presentation 계층은 클라이언트와 접촉하는 가장 근접한 계층이므로
클라이언트 요청을 가로채고(예: JWT 토큰 확인), 인증 결과를 컨트롤러로 전달하기때문입니다.

계층 정리

controller 의 위치

TODO 블로그 분리

Presentation

1. 역할과 책임의 명확한 분리

• 클라이언트와 가장 근접한 곳으로 요청응답 처리 로직과 비즈니스 로직이 혼합되지않습니다.
• 비즈니스 로직과 기술적인 처리 로직이 혼합되지 않으므로 코드의 가독성과 유지보수성이 향상됩니다.

2. 애플리케이션 흐름 관리

• Presentation Layer에서 Controller는 요청을 받아 비즈니스 로직을 실행하는 Application Layer나 Domain Layer와 상호작용하여 결과를 반환합니다. 이 과정에서 애플리케이션의 흐름을 관리하며, 유스케이스를 구체화하고, 요청에 맞는 적절한 결과를 클라이언트에 전달할 수 있습니다.

요약

항목	Presentation Layer	Application Layer	Infrastructure Layer
주 역할	클라이언트와 직접 통신(API 설계, 요청/응답 처리, DTO 변환)	비즈니스 로직 실행 및 유스케이스 관리 (서비스 호출, 도메인 계층과 상호작용)	기술적인 작업 수행(API Gateway, 외부 시스템과의 통합, 기술적 설정)
장점	- 클라이언트 중심 API 설계로 유지보수 용이 - 역할과 책임이 명확 - 테스트가 용이 - 클라이언트 요구사항 변경에 유연	- 단순한 구조로 빠른 개발 가능 - 작은 프로젝트에서 계층 분리 없이 단일 로직 구현 - 계층 간 호출 오버헤드 감소	- 기술적 표준을 준수한 작업 가능 - 외부 시스템과의 통합 및 중계 역할에 적합 - 기술적 로직과 독립된 설계
단점	- 계층 간 호출로 인한 약간의 오버헤드 - 작은 로직도 별도 서비스로 분리해야 할 수 있음	- 클라이언트 요청 처리와 비즈니스 로직이 혼합 - 변경이 많아질 경우 유지보수 어려움 - 테스트 및 재사용성 감소	- 역할 혼란(클라이언트 중심 역할과 혼동 가능) - 유지보수와 확장성 저하 - 기술적인 통합 테스트 필요
적합한 경우	- 사용자와 직접 상호작용하는 API 설계 - 요청/응답 처리, DTO 변환 - 클라이언트 요구사항이 자주 변경되는 경우	- 간단한 애플리케이션에서 Presentation Layer와 통합 - 계층 분리가 필요 없는 소규모 프로젝트	- API Gateway, Webhook과 같은 기술적 통합 - 외부 시스템의 기술적 요청 처리 - 비즈니스와 독립된 기술 작업
테스트 용이성	- 단위 테스트와 클라이언트 중심 테스트가 용이	- 클라이언트와 비즈니스 로직이 혼합되어 테스트가 어려움	- 통합 테스트 필요 (기술적 종속성 증가)
확장성	- 역할 분리로 높은 확장성	- 비즈니스 로직 변경 시 클라이언트 처리에 영향	- 클라이언트 중심 확장에서 부적합