작성한 질문수 30

0

안녕하세요, 진짜 잘하고 싶다 님!

AI 인턴이 잘 설명해주었지만, 책임이라는 것은 Entity와는 전혀 다른 관점입니다.

Post(게시글)을 작성한다고 가정하면 PostService에는 UserRepository를 사용하여 User객체를 얻어야 하는데, 이러한 경우 단일 책임 원칙 위반이라고 얘기할 수 있는 건가요?
댓글을 작성한다고 가정하면, CommentService에 UserRepository, PostRepository를 사용하여 User와 Post 객체를 얻어야 합니다.

이 경우 PostService와 CommentService가 담당하는 책임은 각각 무엇일까요?
PostService라 Post Entity만 사용해야 할 것 같은데, User를 사용하게 되어 단일 책임이 아니게 된걸까요?

그렇지 않습니다. PostService는 '게시글 작성'의 책임, CommentService는 '댓글 작성'의 책임을 가지는 것이고, 이 과정에서 UserRepository를 통해 User 받아 사용하게 되는 현상은 매우 자연스럽습니다.
다른 도메인이 침투한 것이 아니라, 도메인 객체 간 협력이 일어나는 장소가 Service라고 생각하시면 좋습니다.

물론, PostService에서 User의 정보를 직접적으로 변경한다거나 하는 필요 이상의 접근이 생길 경우는 책임이 위반되었다고 볼 수도 있습니다.
이런 경우는 User를 변경하는 일을 맡고 있는 다른 객체에 잘 위임하여 관련 행위를 수행하도록 해야 합니다.

한번 고민해 보세요 ㅎㅎ
감사합니다 🙂

0

안녕하세요, 인프런 AI 인턴입니다.

님의 질문에 대해 답변 드리겠습니다.

1. 단일 책임 원칙(Single Responsibility Principle, SRP)은 하나의 클래스나 모듈이 하나의 기능만을 가지고, 그 기능을 완전히 캡슐화 해야 한다는 원칙입니다. 서비스 레이어에서 다른 도메인의 리포지토리를 참조하여 사용하는 것 자체가 SRP를 위반하는 것은 아닙니다. 중요한 것은 해당 서비스가 담당하는 비즈니스 로직의 ‘책임’과 분리 없이 관련 기능을 수행하는지 여부입니다. 예를 들어, PostService가 UserRepository를 사용해서 사용자 정보를 가져오는 것은, 게시글 작성 기능을 수행하기 위해 필요한 절차일 수 있습니다. 이 경우 PostService는 게시글 작성이라는 한 가지 책임을 지고 있다고 볼 수 있습니다.

2. 다른 도메인의 객체를 서비스 레이어에서 함께 사용한다고 해서 반드시 단위 테스트 작성이 어렵거나 가독성이 떨어지는 것은 아닙니다. 가독성이나 테스트 용이성은 코드의 설계와 구현 방식에 더 크게 영향을 받습니다. 하지만, 도메인 간의 관계가 복잡할수록 이에 대한 이해가 필요하고, 그로 인해 복잡도가 증가할 수 있다는 점은 맞습니다.

3. 개선책으로는 도메인 간의 연관 관계를 최소화하거나, 도메인 서비스를 사용하여 복잡한 비즈니스 로직을 처리하는 방법이 있습니다. 도메인 간의 연관 관계를 최소화하기 위해서는 객체의 결합도를 낮추는 설계 기법들을 고려해볼 수 있습니다. 또한, 복잡한 비즈니스 로직을 별도의 도메인 서비스 레이어에 위임하여 처리하도록 설계하는 것도 한 방법입니다. 이를 통해 각 도메인 클래스나 서비스의 단위 테스트가 용이해지고, 가독성 또한 향상될 수 있습니다. 참고할 만한 책으로는 “클린 코드”, “클린 아키텍처” 같은 로버트 C. 마틴의 시리즈가 있으며, “도메인 주도 설계”에 대한 책도 유용하게 참고하실 수 있습니다.

마지막으로, 강의의 내용이 어렵게 느껴질 수 있지만, 꾸준히 학습하며 실습해 보는 것이 중요합니다. 이론적인 지식 뿐만 아니라, 직접 코드를 작성하면서 이해도를 높여가시길 권장드립니다.

항상 응원합니다!