DDD 4 Layered Architecture + Clean Architecture에서 "중복 검사"에 대한 책임 계층은 어디에서 해야 할까요?

Question

현재 아래와 같이 application usecase를 작성했어요@Slf4j @Service @RequiredArgsConstructor @Transactional public class SignUpUseCase { private final EmailAuthRepository emailAuthRepository; private final MemberRepository memberRepository; private final MemberApplicationMapper mapper; public void execute(SignUpCommand command) { Email reqEmail = command.getEmail(); // 1. 인증된 이메일인지 확인 if (!emailAuthRepository.isEmailVerified(reqEmail)) throw new BusinessException(ErrorCode.EMAIL_VERIFICATION_EXPIRED); // 2. 이미 가입된 이메일인지 확인 if (memberRepository.existsByEmail(reqEmail)) throw new BusinessException(ErrorCode.EMAIL_ALREADY_EXIST); // 3. 이미 존재하는 닉네임인지 확인 // 4. 도메인 엔터티로 변환 Member newMember = mapper.toSignUpMember(command); memberRepository.save(newMember); } }제가 공부한 DDD 4계층은,도메인 계층은 비즈니스 규칙이나 복잡한 비즈니스 규칙을 정의할 때 사용하는 곳으로 알고 있습니다.그리고 위에 회원가입 때 인증된 이메일인지 확인하거나, 이미 가입된 이메일인지 확인하는 기능처럼이메일·아이디 중복 검사 같은 “단순 조회”는 순수 비즈니스 규칙이라기보다 인프라 레벨에서 해결 가능한 제약 사항이므로, Application 계층에서 바로 Repository를 통해 수행해도 무방하다고 알고 있습니다.일각에서는 이를 Domain service에 둘 경우 Domain -> Infra에 의존하는 형태가 될 수도 있다고 하는데사실 이 부분은 잘 공감 못하겠는게, 어차피 인터페이스로 의존하니까 DIP는 성립되는 거로 알고 있거든요그런데 위 내용을 또 다른 시각에서는"어떤 처리가 도메인에 중요한 기능이라면 이는 도메인 서비스에 위치해야 합니다. 다시 말하면 사용자 중복 처리가 애플리케이션의 도메인 해석적으로 봤을 때 분명히 도메인 모델이 해야 할 역할이라면 이는 도메인 서비스에 위치해야 합니다. 사용자명 중복은 도메인에 기초한 개념입니다.하지만 어떤 기능이 애플리케이션을 구동시키기 위한 기능이지 도메인에 중요한 기능이 아니라면 이는 도메인 서비스에 위치하면 안됩니다.영속성을 위한 데이터스토어는 도메인에 입각한 지식이 아닙니다. 이는 어플리케이션을 구동시키기 위해 존재하는 것이지요.따라서 이를 도메인 서비스에 위치시키면 안된다는 관점도 존재합니다.이러한 기능은 애플리케이션 서비스에 위치시킵니다."라고 합니다.이때 도메인 해석적이라는 말이 좀 굉장히 어렵게 다가오네요.제가 생각한 비즈니스 규칙은이를테면, 이메일의 형식, 비밀번호의 제약사항..(이런 건 vo레벨에서 처리 가능)주문할 때, 이를테면 10만원 이상 주문 시 할인 적용이라 할 때 단일 vo에서 처리하지 못하니,여러 vo를 통한 복잡한 비즈니스 규칙을 정의할 때domain service를 사용하는 거로 이해하긴 했습니다.질문글을 작성하다 보니 좀.. 우왕좌왕 작성된 거 같아, 제가 지금 어려워 하는 부분을 정리해서 다시 말씀드리겠습니다.단순히 영속성이나 기술적 필요성에서 기인한 검사(DB 테이블 구조, 인증 토큰 검증 등)라면 애플리케이션 계층에서 처리하는 것이 맞다고 판단되지만, 이를 도메인 해석적으로 봤을 때 도메인 모델이 해야 할 역할이라면 도메인 서비스에 위치해야 한다는 것이 좀 어렵게 느껴집니다.(그래서 통일성을 위해 그냥 영속성 제외한 모든 건 다 domain service에서 처리하도록 할까.. 고민도 되긴 하네요. 근데 이러면 DDD를 쓰는 의미가 없으니...ㅠ)

개못남 · Answer

DB 조회가 필요한 검증(중복 검사 등) - 도메인 서비스 처리도메인 객체 자체에서 처리 가능한 검증 - 도메인 객체 자체에서 처리저는 이렇게 사용하고 있어요.필요시 도메인 서비스를 만드는건 좋으나, 모든 처리를 도메인 서비스에서 처리하는건 반대로 도메인 객체 자체의 의미가 없어지지 않나 라는 생각이 드네요.(단순 속성만 가지는 객체가 만들어질테니..)

chytonpide · Answer

https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/여기 딱 중복확인 로직이 어디에 위치해야 하는지에 대한 좋은 아티클이 있습니다.어플리케이션 레이어는 도메인 모델을 준비시키고 실행시키는 역할을 합니다.도메인 모델은 도메인 지식에 기반해서 결정을 합니다. 하지만 실제 구현을 하다보면 성능, 순수성, 완전성의 트릴레마가 발생합니다.보통 이경우 완전성을 희생하는게 좋습니다. (성능 및 순수성을 선택합니다.) 이렇게 하면 도메인 로직이 어플리케이션 레이어에 유츌 됩니다. (전 이렇게 유출된 도메인 로직에는 주석을 달아놓습니다.)도메인 로직은 이미 충분히 어렵기 때문에 도메인의 순수성 유지는 필수적입니다.이전 댓글에서 이야기 했던것 처럼 의존 방향이 중요합니다. 레이어를 나누는 이유중 하나는 복잡도를 낮게 유지하기 위함입니다.이미 충분히 어려운 도메인 로직에 어플리케이션 로직, 인프라관련 구체적인 로직이 들어서면 유지보수가 힘들어집니다. 가장 먼저 발생하는 해악은 도메인로직만 테스트 하기가 여려워집니다.

chytonpide · Answer

independent 그러면 최종적으로 제가 궁금한 점은, Domain Service에서는 절대 Repository 통신을 수행하면 안 되는 건가요? 해당 Repository가 Domain의 인터페이스라 하더라도요?어떤 프렉티스를 참고하시는지 몰라서, 어디서부터 답변을 드려야할지 모르겠네요 :)레포지토리는 인터페이스로 도메인계층에 정의 됩니다.도메인서비스에서 레포지토리에 의존하는건 흔하고요.백문불여일견이라고 어떻게 구성되는지 보여드리는게 나을수도 있겠네요.[인증을 처리하는 도메인 서비스]public class AuthenticationService { private final PasswordEncryptionService passwordEncryptionService; private final UserRepository userRepository; public AuthenticationService( PasswordEncryptionService passwordEncryptionService, UserRepository userRepository) { this.passwordEncryptionService = passwordEncryptionService; this.userRepository = userRepository; } public User authenticate(String emailAddress, String rawPassword) { User user = this.userRepository.findByEmailAddress(emailAddress); if (user == null) { return null; } if (!this.passwordEncryptionService.matchedPassword(rawPassword, user.encryptedPassword())) { return null; } return user; } }[도메인계층]mock 은 신경쓰지 않으셔도 됩니다. 도메인 모델의 일부 생성자가 package-private 고, 이 생성자를 사용하기 위해서 mock 도 같은 페키지에 위치시켰습니다.[인프라스트럭쳐 계층]

Iswn · Answer

코드가 늘어나고 수고로운 작업이 해야한다는 단점을 수용하면서 DDD를 쓰려는 이유가위의 단점보다 순수한 도메인로직의 격리가 주는 가치가 높게 평가했기 때문에 DDD를 사용하기로 결정했을 겁니다.그렇다면 도메인로직이 제대로 동작하도록 여타 기술코드가 받쳐주는 구성을 유지하세요.테이블 구조가 바뀌고 DB 튜닝을 위해 테이블이 하나에서 2개로 쪼개져도 도메인 코드는 영향을 받지 않도록 하세요.바로 이를 위해 도메인서비느니 어플리케이션 서비스를 구별하는거죠.여담으로 ..여기서 10만원 이상 주문 시 할인적용은 비즈니스 규칙입니다.이메일 형식, 비밀번호, (혹은 이름의 최소길이 최대길이) 제약사항은 비즈니스 규칙은 아니고 필드의 속성입니다.그래서 이런것은 Bean 유효성검사로 처리하는 영역이죠.(반대로 10마원...할인적용은 업무규칙이니 Bean 유효성검사로 하면안되고 하기도 어렵죠)

wharup · Answer

DDD의 DomainService는 Entity, Value Object와 같은 레벨이니까요Entity가 Repository를 참조하는 게 어색하다면 DomainService 역시 Repository를 참조하지 않아야합니다.그래서 올리신 질문은 결국 Entity가 Repository를 참조해도 되는 지에 대한 것이라고 생각합니다.chytonpide님이 링크한 Vladimir Khorikov의 글에 다음과 같은 방법이 나오는데요① 초기에 모든 값을 다 읽고, 로직 처리 후에, 모두 저장② Application Service(Controller)가 DB가 필요한 체크를 분담③ Entity에 Repository를 인터페이스나 펑션으로 변형해서 넣는 방법질문하신 케이스는 ①은 성능 이슈로 안될 거고, 결국 ②나 ③을 선택하는 건데이 부분은 DDD 쪽에서도 사람마다 생각이 다른 것 같습니다만.. 저는 ②가 좋더라고요 ^^;

장독깨기 · Answer

댓글에 좋아요, 싫어요, 좋아요 취소, 싫어요 취소, 그리고, 좋아요, 싫어요를 남길때 한줄평은 필수 입력 값이다.이 기능의 예제 코드를 만들어달라 제미니에게 부탁을 좀 했습니다. 제미니 참 훌륭합니다. ㅎㅎ주어진 요구사항에 따라 '좋아요', '싫어요', '좋아요 취소', '싫어요 취소' 기능과 한 줄 평 필수 입력 값 검증 로직이 모두 포함된 DDD 예제 코드를 다시 보여드리겠습니다. jakarta.validation을 이용한 필수값 체크는 요청 DTO 레벨에서 이루어지며, 이를 통해 깔끔하고 견고한 코드를 유지할 수 있습니다.전체 DDD 예제 코드 (좋아요, 싫어요, 한 줄 평 필수)1. 도메인 모델 (Domain Model)Comment 엔티티 (댓글 정보 및 좋아요/싫어요 수)Java// domain/model/Comment.java package com.example.dddexample.domain.model; import jakarta.persistence.*; import lombok.*; @Entity @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Table(name = "comments") public class Comment { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private Long authorId; private String content; private int likesCount; private int dislikesCount; @Builder public Comment(Long authorId, String content) { this.authorId = authorId; this.content = content; this.likesCount = 0; this.dislikesCount = 0; } // 좋아요 수 증가 public void incrementLikesCount() { this.likesCount++; } // 좋아요 수 감소 public void decrementLikesCount() { if (this.likesCount > 0) { this.likesCount--; } } // 싫어요 수 증가 public void incrementDislikesCount() { this.dislikesCount++; } // 싫어요 수 감소 public void decrementDislikesCount() { if (this.dislikesCount > 0) { this.dislikesCount--; } } } Like 엔티티 (좋아요 기록 및 한 줄 평)Java// domain/model/Like.java package com.example.dddexample.domain.model; import jakarta.persistence.*; import lombok.*; @Entity @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Table(name = "likes") @Table(uniqueConstraints = @UniqueConstraint(columnNames = {"userId", "commentId"})) // 한 사용자가 한 댓글에 한 번만 좋아요 가능 public class Like { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private Long userId; private Long commentId; private String oneLinerComment; // 한 줄 평 @Builder public Like(Long userId, Long commentId, String oneLinerComment) { this.userId = userId; this.commentId = commentId; this.oneLinerComment = oneLinerComment; } public void updateOneLinerComment(String newComment) { this.oneLinerComment = newComment; } } Dislike 엔티티 (싫어요 기록 및 한 줄 평)Java// domain/model/Dislike.java package com.example.dddexample.domain.model; import jakarta.persistence.*; import lombok.*; @Entity @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Table(name = "dislikes") @Table(uniqueConstraints = @UniqueConstraint(columnNames = {"userId", "commentId"})) // 한 사용자가 한 댓글에 한 번만 싫어요 가능 public class Dislike { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private Long userId; private Long commentId; private String oneLinerComment; // 한 줄 평 @Builder public Dislike(Long userId, Long commentId, String oneLinerComment) { this.userId = userId; this.commentId = commentId; this.oneLinerComment = oneLinerComment; } public void updateOneLinerComment(String newComment) { this.oneLinerComment = newComment; } } 2. 리포지토리 인터페이스 (Port)CommentRepositoryJava// domain/repository/CommentRepository.java package com.example.dddexample.domain.repository; import com.example.dddexample.domain.model.Comment; import java.util.Optional; public interface CommentRepository { Optional findById(Long id); Comment save(Comment comment); } LikeRepositoryJava// domain/repository/LikeRepository.java package com.example.dddexample.domain.repository; import com.example.dddexample.domain.model.Like; import java.util.Optional; public interface LikeRepository { Optional findByUserIdAndCommentId(Long userId, Long commentId); Like save(Like like); void delete(Like like); } DislikeRepositoryJava// domain/repository/DislikeRepository.java package com.example.dddexample.domain.repository; import com.example.dddexample.domain.model.Dislike; import java.util.Optional; public interface DislikeRepository { Optional findByUserIdAndCommentId(Long userId, Long commentId); Dislike save(Dislike dislike); void delete(Dislike dislike); } 3. 도메인 서비스 (Domain Service)CommentInteractionDomainService (상호작용 관련 도메인 규칙 검증)Java// domain/service/CommentInteractionDomainService.java package com.example.dddexample.domain.service; import com.example.dddexample.domain.repository.LikeRepository; import com.example.dddexample.domain.repository.DislikeRepository; import com.example.dddexample.common.exception.BusinessException; // 예외 처리 (별도 구현 필요) import lombok.RequiredArgsConstructor; import org.springframework.stereotype.Service; @Service @RequiredArgsConstructor public class CommentInteractionDomainService { private final LikeRepository likeRepository; private final DislikeRepository dislikeRepository; // 특정 사용자가 특정 댓글에 이미 좋아요를 눌렀는지 확인 public boolean isAlreadyLiked(Long userId, Long commentId) { return likeRepository.findByUserIdAndCommentId(userId, commentId).isPresent(); } // 특정 사용자가 특정 댓글에 이미 싫어요를 눌렀는지 확인 public boolean isAlreadyDisliked(Long userId, Long commentId) { return dislikeRepository.findByUserIdAndCommentId(userId, commentId).isPresent(); } // 좋아요 또는 싫어요를 누르기 전에 충돌하는 상호작용이 없는지 확인하는 비즈니스 규칙 // (예: 좋아요 누르려는데 이미 싫어요가 눌려있으면 안 됨) public void validateNoConflictingInteraction(Long userId, Long commentId) { if (isAlreadyLiked(userId, commentId)) { throw new BusinessException("User has already liked this comment. Cannot perform conflicting action."); } if (isAlreadyDisliked(userId, commentId)) { throw new BusinessException("User has already disliked this comment. Cannot perform conflicting action."); } } } 4. 애플리케이션 서비스 (Application Service)CommentInteractionRequest DTO (요청 데이터 및 한 줄 평 필수 검증)Java// application/dto/CommentInteractionRequest.java package com.example.dddexample.application.dto; import jakarta.validation.constraints.NotBlank; // 필수 입력 값 검증을 위한 import import jakarta.validation.constraints.NotNull; import lombok.Getter; import lombok.NoArgsConstructor; import lombok.Setter; @Getter @Setter @NoArgsConstructor public class CommentInteractionRequest { @NotNull(message = "User ID cannot be null") private Long userId; // @NotBlank: 문자열이 null이 아니고, 비어있지 않으며, 공백으로만 구성되지 않음을 검증합니다. @NotBlank(message = "One-liner comment cannot be blank") private String oneLinerComment; } CommentInteractionAppService (유스케이스 처리 및 도메인 객체 조율)Java// application/CommentInteractionAppService.java package com.example.dddexample.application; import com.example.dddexample.application.dto.CommentInteractionRequest; import com.example.dddexample.domain.model.Comment; import com.example.dddexample.domain.model.Like; import com.example.dddexample.domain.model.Dislike; import com.example.dddexample.domain.repository.CommentRepository; import com.example.dddexample.domain.repository.LikeRepository; import com.example.dddexample.domain.repository.DislikeRepository; import com.example.dddexample.domain.service.CommentInteractionDomainService; import com.example.dddexample.common.exception.ResourceNotFoundException; import com.example.dddexample.common.exception.BusinessException; import lombok.RequiredArgsConstructor; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; @Service @RequiredArgsConstructor public class CommentInteractionAppService { private final CommentRepository commentRepository; private final LikeRepository likeRepository; private final DislikeRepository dislikeRepository; private final CommentInteractionDomainService domainService; // 댓글 좋아요 기능 @Transactional public void likeComment(Long commentId, CommentInteractionRequest request) { Comment comment = commentRepository.findById(commentId) .orElseThrow(() -> new ResourceNotFoundException("Comment not found with id: " + commentId)); // 1. 도메인 규칙 검증: 이미 좋아요/싫어요를 눌렀는지 확인 domainService.validateNoConflictingInteraction(request.getUserId(), commentId); // 2. 좋아요 엔티티 생성 및 저장 (한 줄 평 포함) Like newLike = Like.builder() .userId(request.getUserId()) .commentId(commentId) .oneLinerComment(request.getOneLinerComment()) // DTO에서 유효성 검사된 한 줄 평 사용 .build(); likeRepository.save(newLike); // 3. 댓글의 좋아요 수 증가 comment.incrementLikesCount(); commentRepository.save(comment); } // 댓글 좋아요 취소 기능 @Transactional public void unlikeComment(Long commentId, Long userId) { Like existingLike = likeRepository.findByUserIdAndCommentId(userId, commentId) .orElseThrow(() -> new BusinessException("User has not liked this comment.")); // 1. 좋아요 기록 삭제 likeRepository.delete(existingLike); // 2. 댓글의 좋아요 수 감소 Comment comment = commentRepository.findById(commentId) .orElseThrow(() -> new ResourceNotFoundException("Comment not found with id: " + commentId)); comment.decrementLikesCount(); commentRepository.save(comment); } // 댓글 싫어요 기능 @Transactional public void dislikeComment(Long commentId, CommentInteractionRequest request) { Comment comment = commentRepository.findById(commentId) .orElseThrow(() -> new ResourceNotFoundException("Comment not found with id: " + commentId)); // 1. 도메인 규칙 검증: 이미 좋아요/싫어요를 눌렀는지 확인 domainService.validateNoConflictingInteraction(request.getUserId(), commentId); // 2. 싫어요 엔티티 생성 및 저장 (한 줄 평 포함) Dislike newDislike = Dislike.builder() .userId(request.getUserId()) .commentId(commentId) .oneLinerComment(request.getOneLinerComment()) // DTO에서 유효성 검사된 한 줄 평 사용 .build(); dislikeRepository.save(newDislike); // 3. 댓글의 싫어요 수 증가 comment.incrementDislikesCount(); commentRepository.save(comment); } // 댓글 싫어요 취소 기능 @Transactional public void undislikeComment(Long commentId, Long userId) { Dislike existingDislike = dislikeRepository.findByUserIdAndCommentId(userId, commentId) .orElseThrow(() -> new BusinessException("User has not disliked this comment.")); // 1. 싫어요 기록 삭제 dislikeRepository.delete(existingDislike); // 2. 댓글의 싫어요 수 감소 Comment comment = commentRepository.findById(commentId) .orElseThrow(() -> new ResourceNotFoundException("Comment not found with id: " + commentId)); comment.decrementDislikesCount(); commentRepository.save(comment); } } 5. 인프라 계층 (Infrastructure Layer)CommentRepositoryJpaImplJava// infrastructure/repository/CommentRepositoryJpaImpl.java package com.example.dddexample.infrastructure.repository; import com.example.dddexample.domain.model.Comment; import com.example.dddexample.domain.repository.CommentRepository; import org.springframework.data.jpa.repository.JpaRepository; import org.springframework.stereotype.Repository; import java.util.Optional; public interface CommentJpaRepository extends JpaRepository {} @Repository public class CommentRepositoryJpaImpl implements CommentRepository { private final CommentJpaRepository commentJpaRepository; public CommentRepositoryJpaImpl(CommentJpaRepository commentJpaRepository) { this.commentJpaRepository = commentJpaRepository; } @Override public Optional findById(Long id) { return commentJpaRepository.findById(id); } @Override public Comment save(Comment comment) { return commentJpaRepository.save(comment); } } LikeRepositoryJpaImplJava// infrastructure/repository/LikeRepositoryJpaImpl.java package com.example.dddexample.infrastructure.repository; import com.example.dddexample.domain.model.Like; import com.example.dddexample.domain.repository.LikeRepository; import org.springframework.data.jpa.repository.JpaRepository; import org.springframework.stereotype.Repository; import java.util.Optional; public interface LikeJpaRepository extends JpaRepository { Optional findByUserIdAndCommentId(Long userId, Long commentId); } @Repository public class LikeRepositoryJpaImpl implements LikeRepository { private final LikeJpaRepository likeJpaRepository; public LikeRepositoryJpaImpl(LikeJpaRepository likeJpaRepository) { this.likeJpaRepository = likeJpaRepository; } @Override public Optional findByUserIdAndCommentId(Long userId, Long commentId) { return likeJpaRepository.findByUserIdAndCommentId(userId, commentId); } @Override public Like save(Like like) { return likeJpaRepository.save(like); } @Override public void delete(Like like) { likeJpaRepository.delete(like); } } DislikeRepositoryJpaImplJava// infrastructure/repository/DislikeRepositoryJpaImpl.java package com.example.dddexample.infrastructure.repository; import com.example.dddexample.domain.model.Dislike; import com.example.dddexample.domain.repository.DislikeRepository; import org.springframework.data.jpa.repository.JpaRepository; import org.springframework.stereotype.Repository; import java.util.Optional; public interface DislikeJpaRepository extends JpaRepository { Optional findByUserIdAndCommentId(Long userId, Long commentId); } @Repository public class DislikeRepositoryJpaImpl implements DislikeRepository { private final DislikeJpaRepository dislikeJpaRepository; public DislikeRepositoryJpaImpl(DislikeJpaRepository dislikeJpaRepository) { this.dislikeJpaRepository = dislikeJpaRepository; } @Override public Optional findByUserIdAndCommentId(Long userId, Long commentId) { return dislikeJpaRepository.findByUserIdAndCommentId(userId, commentId); } @Override public Dislike save(Dislike dislike) { return dislikeJpaRepository.save(dislike); } @Override public void delete(Dislike dislike) { dislikeJpaRepository.delete(dislike); } } 6. 표현 계층 (Presentation Layer)CommentController (API 요청 처리)Java// presentation/CommentController.java package com.example.dddexample.presentation; import com.example.dddexample.application.CommentInteractionAppService; import com.example.dddexample.application.dto.CommentInteractionRequest; import jakarta.validation.Valid; // @Valid 어노테이션을 사용하려면 이 import가 필요 import lombok.RequiredArgsConstructor; import org.springframework.http.HttpStatus; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.*; @RestController @RequiredArgsConstructor @RequestMapping("/api/comments") public class CommentController { private final CommentInteractionAppService commentInteractionAppService; // 댓글 좋아요 API (한 줄 평 필수) @PostMapping("/{commentId}/likes") public ResponseEntity likeComment(@PathVariable Long commentId, @Valid @RequestBody CommentInteractionRequest request) { // @Valid 적용 commentInteractionAppService.likeComment(commentId, request); return ResponseEntity.status(HttpStatus.CREATED).build(); } // 댓글 좋아요 취소 API @DeleteMapping("/{commentId}/likes") public ResponseEntity unlikeComment(@PathVariable Long commentId, @RequestParam Long userId) { // 취소는 한 줄 평이 필요 없음 commentInteractionAppService.unlikeComment(commentId, userId); return ResponseEntity.noContent().build(); } // 댓글 싫어요 API (한 줄 평 필수) @PostMapping("/{commentId}/dislikes") public ResponseEntity dislikeComment(@PathVariable Long commentId, @Valid @RequestBody CommentInteractionRequest request) { // @Valid 적용 commentInteractionAppService.dislikeComment(commentId, request); return ResponseEntity.status(HttpStatus.CREATED).build(); } // 댓글 싫어요 취소 API @DeleteMapping("/{commentId}/dislikes") public ResponseEntity undislikeComment(@PathVariable Long commentId, @RequestParam Long userId) { // 취소는 한 줄 평이 필요 없음 commentInteractionAppService.undislikeComment(commentId, userId); return ResponseEntity.noContent().build(); } } 7. 공통 계층 (Common Layer) - 예외 처리ResourceNotFoundExceptionJava// common/exception/ResourceNotFoundException.java package com.example.dddexample.common.exception; import org.springframework.http.HttpStatus; import org.springframework.web.bind.annotation.ResponseStatus; @ResponseStatus(HttpStatus.NOT_FOUND) // 404 Not Found public class ResourceNotFoundException extends RuntimeException { public ResourceNotFoundException(String message) { super(message); } } BusinessExceptionJava// common/exception/BusinessException.java package com.example.dddexample.common.exception; import org.springframework.http.HttpStatus; import org.springframework.web.bind.annotation.ResponseStatus; @ResponseStatus(HttpStatus.CONFLICT) // 409 Conflict (비즈니스 규칙 위반 시) public class BusinessException extends RuntimeException { public BusinessException(String message) { super(message); } } 코드의 핵심 및 DDD 원칙한 줄 평 필수 검증: CommentInteractionRequest DTO의 oneLinerComment 필드에 @NotBlank 어노테이션을 추가하여 필수 입력 값 검증을 선언했습니다. CommentController에서 @Valid 어노테이션을 사용하여 이 DTO를 받으면, Spring의 유효성 검사기가 자동으로 이 규칙을 적용합니다. 유효성 검사 실패 시, 컨트롤러 메서드가 실행되기 전에 예외가 발생하여 애플리케이션 서비스 계층으로 잘못된 데이터가 전달되는 것을 방지합니다.명확한 도메인 모델: Comment, Like, Dislike 각 엔티티는 고유한 책임과 행위(Behavior)를 가집니다. 예를 들어, Comment는 좋아요/싫어요 수 증가/감소에 대한 책임을 직접 수행합니다.강력한 도메인 서비스: CommentInteractionDomainService는 "한 사용자가 한 댓글에 좋아요와 싫어요를 동시에 누를 수 없다"는 것과 같은 여러 애그리거트(Like, Dislike)에 걸친 핵심 비즈니스 규칙을 캡슐화하고 검증합니다.간결한 애플리케이션 서비스: CommentInteractionAppService는 사용자의 특정 유스케이스를 수행하는 데 집중합니다. 직접적인 도메인 로직 대신, 도메인 모델의 행위와 도메인 서비스의 규칙 검증을 *조율(Orchestration)*하는 역할을 합니다. 트랜잭션 관리도 이곳에서 이루어집니다.분리된 인프라 계층: 리포지토리의 구현체는 infrastructure 패키지에 위치하여 데이터베이스와의 상호작용을 담당하며, 도메인 계층으로부터 분리되어 있습니다.이 예제는 복잡한 비즈니스 요구사항을 DDD의 원칙에 따라 구조화하고, 유효성 검사와 같은 크로스-커팅 관심사를 적절한 계층에서 처리하는 방법을 보여줍니다.

호두까면주름생김 · Answer

DDD 가 아니라 그냥 MVC + Repository 넣은 4 layer transaction script 패턴인것 같음.도메인 서비스는 해당 도메인 컨텍스트에서 MVC 패턴을 따르지 않는 독립적인 기능을 수행해야 할 때 해당 레이어를 사용하는걸로 알고 있음. 이메일 중복을 도메인 규칙으로 볼것이냐, 기술적 관점에서 볼것이냐의 문제인 것 같은데, "중복되도 되나요?" 에서 "네" 라는 대답이 나오면 이걸 도메인 규칙으로 볼지, 기술적 관점으로 볼지 너무 애매하지 않음?그리고 하나의 작은 도메인 엔티티에서 그 엔티티가 표현하고자 하는것은 비지니스 관심사임. 이메일 중복이나 비밀번호 유효성 검사같은건 기술적 관점이고. DDD 를 하려면 도메인에 집중해야함."그럼 어떻게 해야하나요? 뭐가 맞나요?" 에 대한 답변:- 해당 개념(이메일 중복, 무슨 중복 ~ 중복)을 해당 제품을 만드는 모든 사람들이 알아야하는가?if (네) { return 도메인 지식: 엔티티에 때려박으셈 }else { return 기술적 관심사: 인프라보단 application usecase 에 박으셈 }끗결론: 사장님께 물어보셈feat. 인프라에 checker 같은걸 넣지 않고 별도의 usecase 에 넣으라고 제 주관적인 의견을 드리는 이유는 인프라에(자바이므로) 하나의 클래스 파일을 넣는 것이 응집성 측면에서 상당히 부담되는 경우가 있음. 그냥 이럴땐 check 로직을 해당 usecase 나 service 메서드에 걍 넣어두는게 응집성이나 의식의 흐름 측면에서 부담이 덜 가더라고요 저는.

메르시도 힐러입니다 · Answer

저는 "프레임워크(또는 라이브러리)가 바뀌어도 재작성해야 하는 로직이 적은가?"라는 질문이 도움 됐습니다.예를 들어, Spring MVC에서 Spring WebFlux으로 변경할 때 본문의 SignUpUseCase를 재작성해야 하고, 이 과정에서 비즈니스 규칙 검증이나 테스트 코드가 빠질 가능성이 있습니다.비즈니스 규칙 검증은 가능하면 도메인 모델에서 처리하고, 그게 어려운 경우에 애플리케이션 계층에서 처리하는 걸 추천합니다. (DB 조회가 필요 없는) 입력 유효성 검증은 입력 모델에서 추리하는 걸 추천합니다.입력 모델과 도메인 모델은 POJO로 구현하세요.

DDD 4 Layered Architecture + Clean Architecture에서 "중복 검사"에 대한 책임 계층은 어디에서 해야 할까요?

8개의 답변

#clean-architecture 목록