서비스 계층을 만드는 것이 얼마나 중요합니까?

3 개 계층 (DAL, BL, UI)으로 앱을 구축하기 시작했습니다. 주로 CRM, 일부 판매 보고서 및 인벤토리를 처리합니다.

동료가 서비스 계층 패턴으로 전환해야한다고 개발자가 경험을 바탕으로 서비스 패턴을 도입했으며 대부분의 애플리케이션을 설계하는 더 좋은 방법이라고 말했습니다. 그는 미래에 그런 식으로 애플리케이션을 유지하는 것이 훨씬 쉬울 것이라고 말했다.

개인적으로, 나는 그것이 단지 일을 더 복잡하게 만들고 있다는 것을 느끼고 그것을 정당화 할 수있는 이점을 많이 볼 수 없었습니다.

이 응용 프로그램에는 데스크톱 응용 프로그램 기능 중 일부 (그러나 소수는 아님)를 사용하는 작은 부분 UI가 추가되어 있으므로 코드를 많이 복제하지는 않았습니다. 코드 중복으로 인해 서비스 지향으로 변환하지는 않지만 일반적으로 매우 훌륭한 아키텍처이기 때문에 프로그래머는 왜 서비스에 대해 열정적입니까?

나는 그것에 구글을 시도했지만 여전히 혼란스러워하고 무엇을 해야할지 결정할 수 없습니다.

Martin Fowler의 저서 "엔터프라이즈 아키텍처 패턴"은 다음과 같이 말합니다.

대답하기 쉬운 질문은 아마 사용하지 않을 때입니다. 애플리케이션의 비즈니스 로직에 하나의 클라이언트 (예 : 사용자 인터페이스) 만 있고 서비스 사례 응답에 여러 트랜잭션 리소스가 포함되지 않는 경우 서비스 계층이 필요하지 않을 수 있습니다. [...]

그러나 두 번째 종류의 클라이언트 또는 사용 사례 응답의 두 번째 트랜잭션 리소스를 구상하자마자 처음부터 서비스 계층에서 설계 비용을 지불합니다.

서비스 계층이 제공하는 이점은 서로 다른 클라이언트가 사용할 수있는 공통 응용 프로그램 작업 집합을 정의하고 각 작업의 응답을 조정한다는 것입니다. 비즈니스 논리를 소비하고 여러 트랜잭션 리소스와 관련된 복잡한 사용 사례가있는 둘 이상의 클라이언트가있는 응용 프로그램이있는 경우 관리 트랜잭션과 함께 서비스 계층을 포함하는 것이 좋습니다.

CRM, Sales 및 Inventory를 사용하면 거의 항상 서비스 계층 작업과 일대일로 대응되는 많은 CRUD 유형 사용 사례가 있습니다. 도메인 개체의 생성, 업데이트 또는 삭제에 대한 응답은 서비스 계층 작업에 의해 원자 적으로 조정되고 처리되어야합니다.

서비스 계층의 또 다른 이점은 로컬 또는 원격 호출 또는 둘 다를 위해 설계 될 수 있으며 유연성을 제공한다는 것입니다. 이 패턴은 애플리케이션 비즈니스 로직의 캡슐화 된 구현과 다양한 클라이언트가 일관된 방식으로 해당 로직을 호출하기위한 토대를 마련합니다. 즉, 클라이언트가 동일한 공통 서비스를 공유하므로 코드 중복을 줄이거 나 제거 할 수 있습니다. 비즈니스 로직이 변경 될 때 일반적으로 각 클라이언트가 아닌 서비스 만 변경하면되므로 유지 관리 비용도 절감 할 수 있습니다.

요약하면, 서비스 계층을 사용하는 것이 좋습니다. 더 많은 예에서는 귀하가 제공 한 비즈니스 논리의 여러 클라이언트가있는 것처럼 들리므로 귀하가 제공 한 것으로 생각합니다.

당신이 아이디어를 평가하고 가장 좋은 방법을 체결했기 때문에 서비스 레이어를 추가 : 좋은

모든 멋진 아이들이하는 일이기 때문에 서비스 계층 추가 : 나쁜

장이 필요 없다고 말하면 만들지 마십시오.

지난 10 년 동안 프로그래밍 세계에서 가장 실망스러운 발전 중 하나는 사람들이 마치 이번 시즌의 신발처럼 트렌드와 악 대차를 따르는 성가신 '패션'지향이되었다는 것입니다. 함정에 빠지지 마십시오. 다음 시즌 '모두'는 다른 방법으로 디자인해야한다고 말할 것입니다.

서비스 계층에는 아무런 문제가 없습니다. 이는 현재 프로젝트의 기술적 장점에 대한 적합성을 평가해야하는 특별한 접근 방식입니다. 다른 사람들의 의견을 자신의 판단으로 대체하도록 강요받지 마십시오.

서비스 계층 생성 결정에는 여러 가지 요소가 있습니다. 다음과 같은 이유로 과거에 서비스 계층을 만들었습니다.

1. 여러 클라이언트가 재사용해야하는 코드입니다.
2. 라이센스가 제한된 타사 라이브러리.
3. 시스템에 통합 지점이 필요한 타사
4. 중복 된 비즈니스 로직을 중앙 집중화합니다.

사례 1 : 수많은 다른 클라이언트가 사용해야하는 기본 기능을 작성 중입니다. 서비스 계층은 다른 클라이언트가 제공하는 기능을 즉시 사용할 수 있도록 기능을 빌드합니다.

사례 2 : 일반적으로 앱 공간에서 코드를 호스팅하지만 라이센스가 제한된 타사 라이브러리를 사용하고 있습니다. 이 경우 어디에서나 사용하려는 리소스가 있지만 제한된 수의 리소스 만 있습니다. 서비스 뒤에 호스팅하면 전체 조직이 각 개별 호스팅에 대한 라이센스를 구매하지 않고도 응용 프로그램에서 서비스를 사용할 수 있습니다.

사례 3 : 귀하는 제 3자가 귀하에게 연락 할 수있는 기능을 구축하고 있습니다. 예를 들어 공급 업체가 들어오는 제품 발송물에 대한 메시지를 전달할 수 있도록 재고 엔드 포인트를 설정할 수 있습니다.

사례 4 : 코드 전체를 분석 한 결과, 별도의 팀이 동일한 것을 만들었습니다 (약간 다르게 구현 됨). 서비스 계층을 사용하면 최상의 접근 방식을 선택할 수 있으며 이제 모든 팀에서 서비스를 호출하여 프로세스를 동일하게 구현할 수 있습니다. 중앙 집중식 논리의 또 다른 이점은 버그가 발견 된 경우입니다. 이제 수정 사항을 한 번 배치하면 모든 클라이언트가 동시에 혜택을 누릴 수 있습니다.

이 모든 것은 서비스 계층에 부정적인 영향을 미칠 수 있다고합니다.

1. 시스템 복잡성을 추가합니다. 이전에 디버깅 할 응용 프로그램이 하나 밖에 없었던 곳은 지금 두 개입니다. 프로덕션 문제는 클라이언트 앱 설정, 서비스 앱 설정 또는 올바르게 설정 한 클라이언트 및 서버 앱 간의 통신 문제를 확인해야합니다. 전에 한 번도 해본 적이 없다면 까다로울 수 있습니다.
2. 한 가지 실패 지점. 서비스 중단이 발생하면 모든 클라이언트가 영향을받습니다. 이러한 방식으로 코드를 배포하지 않으면 위험을 줄일 수 있습니다 (이를 완화 할 수있는 방법이 있음).
3. 버전 관리가 더 어려울 수 있습니다. 서비스를 사용하는 하나의 앱이있는 경우 두 애플리케이션 사이에서 인터페이스 변경을 동시에 수행 할 수 있습니다. 여러 클라이언트가있는 경우 V1에있는 사람, V2에있는 사람 및 V1 제거를 조정해야합니다 (모든 사람이 V2로 업데이트 한 것을 알고 있음).

요점은 시스템 서비스 지향을 만드는 것이 항상 슬램 덩크가 아니라는 것입니다. 내 경험상 일반적으로 좋은 생각이지만 (이 방법으로 응용 프로그램을 구성하는 경향이 있음) 자동 결정은 아닙니다. 하루가 끝나면 장단점을 평가하고 상황에 맞는 결정을 내려야합니다.

내가 본 대부분의 서비스 계층은 완전한 혼란입니다. 서비스는 다양한 방법을 사용하는 경향이 있으며 1500 LOC는 드물지 않습니다. 다른 방법은 공통점이 없지만 코드를 공유합니다. 이로 인해 높은 커플 링 과 낮은 응집력이 발생 합니다. 새 작업이 필요할 때마다 코드베이스를 확장하는 대신 코드를 수정해야하기 때문에 OCP 도 위반 합니다. 잘 구성된 서비스 계층은 이론적으로 가능하지만 실제로는 본 적이 없습니다.

CQRS 는 이러한 문제를 해결하고 해당 절차 서비스 계층 중 하나를 생성하지 않아도됩니다.

인터페이스 (서비스 계층은 인터페이스 유형 임)를 추가하는 데 시간이 걸립니다. 좋은 것은 디자인하고 테스트하는 데 많은 시간이 걸립니다. 나중에 변경하면 모든 클라이언트가 중단되므로 첫 번째 시도에서 바로 얻는 것이 매우 중요합니다. 또한 약간 다른 요구를 가진 두 번째 클라이언트가있을 때까지 해당 인터페이스에 무엇이 필요한지 알지 못할 것입니다. 서비스 유지는 그 자체로 끝나지 않는 프로젝트입니다.

대부분의 조직에서 비즈니스 스폰서에게 가서 "다른 예산 부서에서 예산으로 개발중인이 시스템의 이점을 다른 부서에서 활용하기를 원하십니까?" 그들은 당신을 비웃을 것입니다. 먼저 비즈니스 스폰서에게 도움을 요청한 다음 부서의 시간에 해당 코드를 재사용하여 문제를 해결하십시오.

사실 오늘날 작성중인 기능이 여러 다른 서비스 클라이언트에서 재사용 될 것임을 알고 있다면 첫 번째 날부터 서비스 계층을 설계하는 것이 좋습니다. 확실하지 않거나 이미 프로젝트에 미지수가 많은 경우 먼저 간단한 작업을 수행하고 시간과 예산이있는 경우 나중에 서비스와 클라이언트로 분리하십시오. 작업 시스템을 시작할 때 첫 번째 시도에서 서비스 인터페이스를 얻는 것이 훨씬 쉽습니다.

PS Java로 작업하는 경우 Joshua Bloch는 그의 저서 인 Effective Java에서 환상적인 인터페이스 조언을 많이받습니다.

동의합니다. 단일 UI를 사용하는 경우 하나 이상의 레이어를 포함 할 필요가 없습니다.

DAL, BL 및 UI / Controller는 응용 프로그램을 디자인하기에 적합합니다. 단일 UI를 사용하려는 경우 추가 레이어를 준비 할 필요가 없습니다. 응용 프로그램에 1 개 이상의 계층을 포함하면 개발 노력 / 시간 만 증가합니다.

또 다른 schenerio는 응용 프로그램에서 여러 UI를 사용하는 것입니다.이 경우 UI를 처리 할 서비스 계층이있는 것이 좋습니다.

스택 오버플로 : 서비스 계층 패턴에 대한 토론

귀하의 BL이 서비스 계층이라고 주장합니다. 비즈니스 로직이있는 중앙 장소. 논리가 필요한 모든 것이 사용할 수있는 DLL이어야합니다. 그런 다음 앱에 다른 UI가있는 경우 웹 API 레이어를 그 위에 놓을 수 있습니다.