비즈니스 계층 대 서비스 계층의 서비스 참조

Question

나는 비슷한 제목의 질문을 보았지만 성공하지 못했습니다. 비즈니스 레이어에서 다른 비즈니스 엔터티의 데이터를 가져 오기 위해 서비스 참조를 만들 수 있습니까? 아니면 Service Layer에서 수행해야합니까?

Answer 1

이것은 거대한 철학적 토론으로 나선형이 될 수 있기 때문에 대답하기 쉽지 않습니다. 그러나 비즈니스 로직 계층이 다른 비즈니스 엔티티를 가져 오기 위해 서비스 계층으로 되돌아 가야한다고 생각하지 않습니다.

이 시나리오의 일반적인 접근 방식은 비즈니스 로직 위에 외관 레이어를 갖는 것입니다. 이 계층은 여러 비즈니스 엔티티의 검색이 필요할 때 응답을 조정하는 역할을합니다. 그래서 :

서비스 -> 비즈니스 외관 -> 비즈니스 로직 -> 데이터

편집 : 작은, 간단한 앱의, 이것은 과잉이다. 파사드 레이어를 제거하고 서비스가 로직 메소드를 호출하게하거나 서비스가 여러 로직 메소드를 호출하게합니다.

서비스 계층은 실제로 단순한 통과 (pass-through)이며 가능한 적은 로직으로 더 나아집니다. 이를 통해 서비스 레이어를 교체하거나 신뢰할 수있는 앱/서비스가 서비스 호출을 할 필요가 없을 때 로컬 컴퓨터의 외관 레이어를 직접 호출 할 수 있습니다.

이 접근법을 사용하면 외관 수준에 "신뢰의 노선"을 배치하고 보안을 구현할 수 있습니다. 보안 검사가 수행되어야하고, 아마도이 "신뢰의 노선"에서 다른 것들이 수행되어야한다면, 우리는 비즈니스 외관에 대한 하나의 서비스 호출 만 원한다. 그래서 우리는 검색 할 필요가있는 각 엔티티에 대해이 논리를 반복하지 않는다.

외관 층은 단순히 논리 층에서 메소드를 호출하는 메소드 층입니다. facade 메소드는 로직 레이어에서 하나의 메소드를 호출하는 것처럼 간단 할 수 있으며 로직 레이어에서 여러 메소드를 호출하고 적절한 도메인 엔티티 또는 심지어 DTO의 일관된 응답을 조율하는 것과 같이 복잡 할 수 있습니다.

나는 계속할 수있다. 실제로이 토론에 전념하는 전체 책이 있습니다. 다행히 적어도 광범위한 개요와 함께 도움이되기를 바랍니다.