src/
└── main/
    ├── kotlin/
    │   └── com/
    │       └── example/
    │           └── projectname/
    │               ├── application/ 어플리케이션
    │               │   ├── service/ 유스케이스, 서비스 비즈니스 로직 구현체
    │               │   │   └── SomeService.kt
    │               │   └── port/ 
    │               │       ├── in/ 유스케이스, 서비스 비즈니스 로직 추상화 
    │               │       │   └── SomeUseCase.kt
		|								|				|   └── dto/
		|								|				|		   └── dto/ (request, response)
    │               │       └── out/ 외부 시스템, 인프라 계층 추상화
    │               │           └── SomeFeature.kt
    │               ├── domain/ 도메인 
    │               │   ├── model/ 
    │               │   │   └── SomeEntity.kt, SomeVo.kt
    │               │   ├── repository/ 레포 추상화
    │               │   │   └── SomeRepository.kt
    │               │   └── service/ 도메인 전용 서비스 구현체 
    │               │       └── SomeDomainService.kt
    │               ├── infrastructure/
    │               │   ├── configuration/
    │               │   │   └── SomeConfiguration.kt
    │               │   ├── repository/ 레포 구현체
    │               │   │   └── SomeJpaRepository.kt
    │               │   └── adapter/ 외부 인프라 통신 어댑터 (연결) 
    │               │       └── SomeRepositoryImpl.kt
    │               └── presentation/
    │                   ├── controller/
    │                   │   └── SomeController.kt
    │                   ├── dto/
    │                   │   ├── request/
    │                   │   │   └── SomeRequestDto.kt
    │                   │   └── response/
    │                   │       └── SomeResponseDto.kt
    │                   └── mapper/ 입력 및 반환 값 매핑
    │                       └── SomeMapper.kt
    └── resources/
        ├── application.yml
        └── static/

Description

• application: 서비스와 포트 정의가 포함된 계층

  • service: 유스케이스 구현체, 도메인 서비스, 어댑터 를 조합하여 사용
  • port
    • in: 유스케이스 인터페이스
      • dto( request, response [ 필요에 따라 프레젠테이션 dto와 통합가능 ] )
    • out : 외부 시스템 인터페이스(db, redis)
  • domain: 도메인 모델과 도메인 서비스 계층.
    • model: 엔티티, 밸류 오브젝트, 도메인 이벤트 등 도메인 객체를 정의.
    • repository: 도메인 레벨의 리포지토리 인터페이스를 정의.
    • service: 도메인 서비스를 정의, 필요에 따라 추상화 계층 분리 가능.
  • infrastructure: 인프라 계층을 포함합니다.
    • configuration: 빈 설정과 같은 구성 관련 클래스를 정의.
    • repository: 외부 인프라 서비스 접근 관련 구현체를 포함. (예: JPA 리포지토리).
    • adapter: 외부 인프라 시스템과의 통신을 담당하는 어댑터를 포함합니다. (예: 카프카, ES)
  • presentation: 프레젠테이션 계층을 포함합니다.
    • controller: REST 컨트롤러 또는 웹 컨트롤러를 정의합니다.
    • dto: 요청 및 응답 DTO를 정의합니다.
      • request: 클라이언트로부터 들어오는 요청 데이터를 담는 DTO.
      • response: 클라이언트로 나가는 응답 데이터를 담는 DTO.
    • mapper: DTO와 도메인 모델 간의 변환 로직을 정의합니다.
  • flow example
    • 클라이언트 요청:
      • 클라이언트가 /api/documents에 POST 요청을 보내면 DocumentController가 이를 처리합니다.
    • 프레젠테이션 레이어:
      • DocumentController는 요청을 CreateDocumentUseCase 인터페이스를 통해 애플리케이션 레이어로 전달합니다.
    • 애플리케이션 레이어:
      • DocumentService는 요청을 처리하기 위해 DocumentDomainService를 호출하여 도메인 로직을 검증합니다.
      • 검증 후 DocumentRepository를 통해 문서를 저장합니다.
    • 도메인 레이어:
      • DocumentDomainService는 비즈니스 로직을 구현합니다.
      • DocumentRepository는 도메인 모델을 영속화하기 위한 인터페이스입니다.
    • 인프라 레이어:
      • DocumentRepositoryImpl은 JPA를 사용하여 데이터베이스와 상호작용합니다.
    • 응답 반환:
      • DocumentController는 애플리케이션 서비스에서 반환된 DTO를 클라이언트에 응답합니다.

  의문점

  • 왜 도메인 서비스가 별도의 추상화를 가지지 않는가?
    • 도메인 서비스는 모델간의 상호작용을 정의하고 객체 상태를 변경하는 로직이 대부분.
    • 도메인 서비스는 도메인 모델의 일부로써 특정 도메인 로직을 구현하는데 집중함 실제 데이터 조합은 어플리케이션 쪽에서 하므로 별도로 추상화를 하지 않는게 일반적.
  • 어플리케이션은 왜 존재하는가?
    • 비즈니스 요구사항을 만족하기 위해서 존재함.
    • 실제 요구사항을 만족하기위해 도메인 서비스와 상호작용 및 조율을 통해 원하는 결과를 가짐.
    • 따라서 인터페이스가 있으면 필요에 따라 추가적인 구현체를 작성해 유연성, 확장성 보장.
  • 도메인과 인프라 레포는 왜 비슷한데 따로 존재하는가?
    • Spring에서는 일반적으로 JPA인터페이스를 상속 하기에 사용을 잘 안함.
    • 하지만 커스텀 레포를 구현하면 엔티티 매니저를 초기화해 사용가능.
    • 다른 언어에서는 더욱더 확실하게 사용가능
    • 하지만 커스텀 레포를 구현하는 영역은 아직 경험해보지 못해 익숙하지 않아서 의문점이 듬. 조금 더 고민해 보면 도메인 레포를 추상화 한다면 인터페이스를 통해 계층간의 결합도를 낮추고 유연성이 높아질수 있음 → 필요에 따라 동일한 추상화를 다르게 구현 하면 됨
    • Mock 객체를 통해 테스트가 용이해짐
  • 프레젠테이션 DTO와 어플리케이션 DTO는 유사한데 왜 따로 두는가?
    • 사실상 거의 같은 값을 받고 반환할텐데 왜 별도로 존재해야 할까? 하지만 이렇게 된다면 두 게층의 역활과 책임이 유사해짐
    • 명확한 역활, 계층 분리가 필요 프레젠테이션 레이어는 클라이언트와 상호작용 어플리케이션 레이어는 비즈니스 로직 담당 각각의 레이어는 자신의 책임에만 집중해야 한다.
    • 또한 클라이언트의 요구사항이 변경되거나 추가적인 클라이언트가 필요한경우 프레젠테이션 레이어의 DTO만 수정하면 됨
    • 또한 각각의 DTO가 독립적으로 변경될수 있음