보통 레이어드 아키텍처는 Controller - Service - Repository로 이어지는데, 현재 한 API 를 사용하면 여러 개념 (예를 들면 유저, 프로덕트 등) 이 서로 협력을 하게 되는 상황입니다.
여기에서 컨트롤러 레이어에서 다른 개념의 서비스를 의존해서 여러 서비스 레이어가 협력하는 설계가 괜찮은 설계일까요?
아니면 파사드 계층을 추가해서 컨트롤러 레이어 에서는 그냥 파사드만 간단하게 의존해서 추상화 하는게 맞을까요? 답이 없지만 좀 더 괜찮은 설계가 무엇일지 고민되어 질문드립니다.
진짜 답이 없는데. 자주 쓰이거나 너무 복잡하거나 도메인에 가까운 로직이다 싶으면 합칠수 있는거임
한 프로젝트 안에서도 고정 컨벤션인게 아니라 유동적으로 감. 주문같은 복잡한 도메인은 보통 서비스 계층 나눠서 완전 위임하고, 검색같은 류는 서비스 여러개 쓸수도 있고
완벽한 하나의 정답이라는건 없음. 그냥 여러가지 많이 경험해보고, 팀 컨벤션이나 최대한 복잡도 낮아보이는걸 선택해야함 1) 컨트롤러가 여러 서비스를 의존함 2) 서비스가 여러 리포지토리를 의존하게 함 3) 서비스에 계층을 적용하여 상위 서비스 안에 여러 하위 서비스를 의존하게 함 4) 리포지토리에 계층을 적용하여 상위 레포지토리 안에 여러 하위 레포지토리를 의존하게함
나중에 의존 안꼬이려면 퍼싸드가 좋은거같아
헷갈릴땐 로직의 흐름을 그려보면 좋습니다 윗 댓글처럼 컨트롤러는 서비스의 의존을 낮추는게 좋으나 서비스 내에서 로직이 복잡해서도 안됩니다 하나의 흐름으로 흐르고 여기저기 왕복한다면 로직이 잘못된건지 확인해보는 것이 좋습니다 가장 간단한 방법은 import를 확인하는 방법도 있습니다.