구조

• DDD 아키텍처 구조

DDD 아키텍처란

장단점

• 도메인 주도 설계
• 장점
  • 규칙이 domain 안에 명확히 드러나 유지보수/확장 용이
  • application(usecase)로 트랜잭션/흐름이 분리되어 테스트 편함
  • infrastructure로 기술 분리
  • 기능 단위로 모듈화가 자연스러워 msa로의 분할도 수행
• 단점
  • 작은 프로젝트에선 과설계 위험
  • 코드 파일 수와 계층이 늘어 초반 생산성이 낮을 수 있음

예시

• Board.save() 같은건 왜 Entity 안에 두지 않고, BoardRepository라는 인터페이스와 BoardRepositoryAdapter를 거치는지

1. 도메인은 “규칙”만 책임

   • Board는 게시글이라는 개념과 규칙을 표현하는 순수 객체
     • 작성자만 수정 가능
     • 제목은 200자 이내
     • 내용은 비어 있으면 안됌
   • 하지만 DB 저장/조회는 규칙이 아니라 기술에 관련된 문제
     • DB를 아는 순간 Board는 더 이상 순수한 도메인 객체가 아님

2. 의존성 역전(Dependency Inversion)

   • DDD는 도메인 → 인프라스트럭처 방향의 의존성을 끊을려고 함
     • Board가 DB를 직접 다루면, 도메인이 JPA/Hibernate/MySQL 같은 구체 기술에 의존하게 됨
     • 그러면 나중에 DB를 MongoDB나 kafka, 파일 시스템으로 바꾸고 싶을 때 Board를 뜯어고쳐야 함
     • 그래서 도메인은 저장이라는 행위(save)를 추상화한 BoardRepository 인터페이스만 알고 실제 DB구현은 인프라 계층 BoardRepositoryAdapter에 위임

Port & Adapter 패턴

BoardRepository(인터페이스)에 findById, search를 정의한 이유

• BoardRepository(Port)

  ⇒ 도메인이 필요로 하는 저장/조회 기능의 계약만 정의

  • save(Board board)
  • findById(Long id)
  • deleteById(Log id)
  • search(String keyword, Pageable pagealbe)

⇒ 도메인은 “게시글을 저장/조회해야 한다” 는 요구사항만 알고, DB를 어떻게 쓰는지, JPA인지 Mongo인지 모름