작성한 질문수 39

2

박준형 님, 안녕하세요!

설계 방침에 따라 그럴 수도 있지만, 꼭 그렇지는 않습니다.

실제로 우리가 마주하는 상황은 여러 도메인 객체를 조합하여 비즈니스 로직을 풀어나가야 하는 상황일텐데요.

각 도메인 객체를 담당하는 Service와 Repository를 두고 (ex. ProductService - ProductRepository) 다시 여러 서비스를 참조하는 facade 형태의 Service를 둘 수 있겠지만, (ex. OrderManageService가 ProductService와 OrderService 등을 참조하여 비즈니스 룰에 따라 Order를 생성하고 저장하는 로직을 가지는 형태) 이러한 방식은 효율성이 많이 떨어집니다.
위 예제에서 OrderService, ProductService의 경우 OrderRepository, ProductRepository에 대한 by-pass 형태의 단순한 로직밖에 가지고 있지 않게 됩니다. 그만큼 실효성이 떨어집니다.

그래서 특정 Service에서 여러 Repository를 참조하여 각 도메인 객체의 CRUD를 수행하고, 비즈니스 로직을 전개해 나가는 것이 보다 효율적인 방식이라 할 수 있겠습니다.

도움이 되셨기를 바랍니다.
감사합니다. 🙂

0

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

질문해주신 내용은 서비스와 레파지토리 구조와 관련된 것으로 보입니다. 일반적으로 말씀하신 것처럼 각각의 레파지토리는 주로 해당 도메인과 밀접한 서비스에서만 의존하여 사용하는 것이 일반적인 구조입니다. 이렇게 구성하는 이유는 각각의 도메인 로직을 서비스 레이어에서 캡슐화하여, 도메인 간의 결합도를 낮추고 유지 보수성을 높이기 위함입니다.

하지만 실제 개발 과정에서는 규모, 팀의 정책, 프로젝트의 특성 등 다양한 요소를 고려하여 이러한 원칙을 느슨하게 적용하기도 합니다. 예를 들어, 구현의 간결성을 추구하거나, 특정 도메인 간 긴밀한 협력이 필요한 경우, 한 서비스에서 다른 도메인의 레파지토리에 직접 의존할 수도 있습니다. 또는 효율성, 성능상의 이유로 중간에 다른 서비스 레이어를 거치지 않고 직접 레파지토리에 접근할 수도 있습니다.

따라서 강의에서의 사례처럼 OrderService가 ProductRepository에 직접 의존하는 경우, 이는 강사님이 결정한 특정한 상황의 최적화나 설계상의 선택일 수 있습니다. 이러한 선택을 할 때는 장단점을 충분투히 고려하고, 팀 내에서 충분한 논의를 거쳐 결정하는 것이 중요합니다.

개발에 있어서는 ‘정답’이라고 할 수 있는 구조나 패턴이 항상 있는 것이 아니며, 상황에 따라 최적의 선택을 하는 것이 중요합니다. 따라서 강사님의 경우를 비롯해 다양한 사례를 학습하며, 장단점을 이해하고 자신의 프로젝트에 적용하는 것이 좋습니다.